The Solana Read & Write Capabilities
The Solana Read & Write capabilities provide a secure and reliable service for your workflow to interact with programs on Solana.
- Solana Read: Allows your workflow to fetch consensus-verified data from Solana accounts and programs.
- Solana Write: Allows your workflow to submit cryptographically signed reports to Solana programs.
How it works
When you use the SDK's solana.Client to interact with Solana, you are invoking these underlying capabilities. CRE routes requests to a Solana capability service backed by a ContractReader for reads and the Keystone Forwarder for writes, so your workflow gets consensus-verified results without managing RPC connections or oracle signing directly.
Understanding Solana Read operations
For Solana Read operations, your workflow calls a read method on solana.Client, such as GetAccountInfoWithOpts, then decodes the raw bytes with a generated Codec.Decode<AccountName>(). Multiple DON nodes independently query the underlying ContractReader and reach consensus on the result before it is returned to your workflow.
Learn more in the Onchain Read guide.
Understanding Solana Write operations
The Solana Write capability shares the same conceptual model as EVM Write: your workflow generates a signed report, and the DON submits it to a Keystone Forwarder program onchain. The forwarder verifies the oracle signatures, then cross-program invokes (CPI) your receiver program's on_report instruction.
The secure write flow
- Payload encoding: Your workflow Borsh-encodes the data to deliver and wraps it in a
ForwarderReportstruct containing an account hash. - Report generation:
runtime.report()signs the encoded payload using thesolanaencoder (ecdsa+keccak256). - DON consensus: Multiple DON nodes independently validate the report before any onchain submission.
- Forwarder submission: A DON node calls the Keystone Forwarder program with the signed report and the required accounts.
- Delivery to your program: The forwarder verifies the signatures and CPIs into your receiver program's
on_reportinstruction.
Account layout
Every Solana write request includes a remainingAccounts list. The Keystone Forwarder expects accounts in the following order:
| Index | Account | Writable | Description |
|---|---|---|---|
| 0 | forwarderState | No | The Keystone Forwarder's onchain state account |
| 1 | forwarderAuthority | No | PDA derived from ["forwarder", forwarderState, receiverProgram] under the forwarder program ID |
| 2+ | Receiver accounts | As needed | Accounts your program's on_report instruction requires |
The public keys of all accounts in this list are concatenated and SHA-256 hashed to produce the accountHash field in the report. The forwarder strips indices 0–1 before CPIing into your receiver, so they must be present and in the correct positions.
Key features
- Decentralized consensus: Multiple DON nodes independently verify read results and validate write reports before they are returned to your workflow or submitted onchain.
- Borsh encoding: Payloads use Borsh, the standard serialization format for Solana programs.
- Type-safe bindings: The CLI binding generator creates typed helpers (such as
writeReportFrom<StructName>()) from your Anchor IDL. - Configurable compute budget: Override the default 290,000 compute unit limit via
ComputeConfigfor writes. - Chain selector support: Target Solana Mainnet or Devnet using Chainlink's chain selector system.
Learn more
- Solana Chain Interactions Guide: Learn how to read from and write to Solana programs using the
SolanaClient - Solana Log Trigger: Start a workflow when a Solana program emits a matching event
- Solana Client SDK Reference: Detailed API reference for
SolanaClientand helper functions - Supported Networks: Chain selector values and minimum SDK versions for Solana networks