Commitment Levels

Solana produces a new slot roughly every 400 milliseconds under Proof of History plus Proof of Stake, so the network is constantly extending — and occasionally re-organizing — its most recent slots. Commitment is the dial that tells https://solana.therpc.io/YOUR_API_KEY how settled the data behind your response must be: read at the freshest tip and you get the lowest latency but a chance the slot is dropped on a fork; read at a rooted slot and the answer can never change. This guide explains exactly what processed, confirmed, and finalized mean so you can choose the right level for each call instead of trusting a single default everywhere.

Understanding Commitment

• processed reflects the most recent slot the node has processed. It is the fastest level, but that slot has not been voted on yet and can still be dropped if the cluster forks away from it.
• confirmed reflects a slot that a supermajority of stake has voted on. Reorgs at this depth are extremely rare, which makes confirmed the practical default for most applications that want fresh data.
• finalized reflects a slot that has been rooted by the cluster — irreversible by design. It is the safest level and the conservative default for reads where correctness matters more than freshness.
• Slot mapping. The commitment you pass determines which slot the response is computed against, and that slot is echoed back in the RpcResponse context.slot, so you can always tell how recent an answer is.
• Preflight is separate. The preflightCommitment used by sendTransaction only governs the simulation run before submission. It is independent of the commitment you later pass to getSignatureStatuses when polling for confirmation — set both deliberately.

Choosing a Commitment

1import { Connection, PublicKey } from '@solana/web3.js';
2 
3// Default commitment for the whole connection
4const connection = new Connection('https://solana.therpc.io/YOUR_API_KEY', 'confirmed');
5 
6const pubkey = new PublicKey('9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM');
7 
8// Fast, may be reverted on a fork
9const fast = await connection.getBalance(pubkey, 'processed');
10 
11// Safe, irreversible — use before crediting value
12const safe = await connection.getBalance(pubkey, 'finalized');
13 
14console.log({ fast, safe });

Best Practices

• Credit value only at finalized. Before you treat a transaction as done — crediting a deposit, releasing goods, settling a trade — read at finalized so a fork can never undo the SOL or token movement you acted on.
• Default UI reads to confirmed. For balances, account state, and other reads that should feel live in a dashboard, confirmed gives near-instant freshness with negligible reorg risk.
• Reserve processed for the disposable. Use processed only for low-stakes, latency-sensitive displays you are willing to re-check — a streaming counter or a draft view — never for anything you settle on.
• Match read and confirm commitment. If you confirmed a transaction at confirmed, read its effects at confirmed too. Confirming at one level and reading at a stricter one can briefly show you stale state.
• Mind the lag. finalized trails processed by several slots — well over a second at ~400ms per slot — so do not silently mix the two in one flow and expect them to agree.

See also

• getSignatureStatuses - Read confirmation status with a commitment
• getSlot - Current slot at a given commitment
• getLatestBlockhash - Blockhash at a chosen commitment