How do transactions work on Solana?

With each fee being paid when executing a transaction, it is good to understand how transactions work. A transaction consists of three parts:

one or more instructions
an array of accounts to read or write from
one or more signatures
recent blockhash or nonce

An instruction is the smallest execution logic on Solana. Instructions are a call to update the global Solana state. Instructions invoke programs that make calls to the Solana runtime to update the state (for example, calling the token program to transfer tokens from your account to another account). You can think of an instruction like a function call on an Ethereum smart contract.

A significant difference between Ethereum and Solana is the number of function calls in a single transaction due to the number of instructions. Having multiple instructions per transaction benefits developers as they do not have to create custom smart contracts to chain functions in a single transaction. Each instruction can be a separate function call, done in order in the transaction. Transactions are atomic, meaning if any of these instructions fails, the whole transaction will fail, and you will only pay the transaction fee. This is like failing a transaction due to not setting the correct slippage on Ethereum.

Another key difference to remember would be the use of a recent blockhash instead of an incremental nonce for transactions. When a wallet wants to make a transaction, a recent blockhash will be pulled from the cluster to create a valid transaction. This recent blockhash only makes the transaction valid for 150 blocks after the recent blockhash was retrieved. This prevents long-living transaction signatures from being executed at a much later date.

Cross-Program Invocation (CPI)

A Cross-Program Invocation (CPI) is when one Solana program calls an instruction on another program while the original transaction is executing. CPI is the main way Solana programs compose with one another, but the account model changes how you design the call graph: the transaction must include every account the full CPI chain will read or write before execution begins.

The callee inherits only the signer and writable privileges that the caller received, and the callee spends from the same transaction compute budget. Use invoke when all required signers signed the original transaction. Use invoke_signed when the calling program needs to sign for one of its PDAs with signer seeds.

Commitment levels

RPC reads, subscriptions, and transaction confirmation logic can choose a commitment level. This is the Solana version of deciding how many Ethereum block confirmations to wait for, except the tiers are explicit:

processed: the node's newest processed view. Use it only for optimistic UI or flows that can tolerate rollback.
confirmed: a block voted on by a supermajority of stake. Use it as the default for most production confirmations and user-facing transaction status.
finalized: the strongest confirmation state. Use it before irreversible off-chain actions such as fiat payouts, shipping goods, or final settlement records.

If an RPC method accepts commitment and you omit it, the default is typically finalized. Production clients should still set commitment explicitly so UI latency, indexer behavior, and settlement policy are deliberate.

getConfirmedBlocks (removed)

Migration

Table of Contents