Every time you send a transaction on Solana or read data from the chain, you are implicitly choosing a commitment level. This choice determines how "final" the data is -- whether the information you receive might still change, or whether it is locked in permanently.
For casual wallet users, this happens invisibly. For developers building dApps, trading bots, or payment systems, understanding commitment levels is essential. Choosing the wrong one can mean acting on data that gets rolled back, or waiting unnecessarily long for confirmations that are not needed.
What Are Commitment Levels?
Commitment levels tell the RPC node how much consensus a block needs to have reached before it returns data to you. Solana has three levels, each representing a different stage in the block confirmation process.
Think of it like a document approval workflow. "Processed" means someone drafted it. "Confirmed" means a majority of reviewers approved it. "Finalized" means it is signed, sealed, and cannot be changed.
The Three Levels
| Level | What It Means | Typical Latency | Can It Be Rolled Back? |
|---|
processed | Block has been received and processed by the connected node | ~400ms | Yes -- possible (rare) |
confirmed | Block has been voted on by a supermajority (66%+) of stake | ~400ms-1s | Extremely unlikely |
finalized | Block has reached maximum lockout (31+ confirmations) | ~6-12s | No -- permanent |
Processed: Fast but Fragile
When you use processed commitment, the RPC node returns data as soon as it has processed the block locally. This is the fastest response you can get, but it comes with a caveat: the block has not yet been confirmed by the broader network.
In practice, processed blocks very rarely get rolled back on Solana. The network's continuous block production and leader schedule make forks uncommon. But "very rarely" is not "never."
When to Use Processed
- Real-time price feeds where displaying slightly stale data is acceptable
- UI updates that will be refreshed shortly anyway
- Monitoring and analytics where speed matters more than absolute accuracy
- Non-financial reads like fetching account metadata
When NOT to Use Processed
- Confirming payment receipt
- Executing trades based on on-chain state
- Any situation where acting on rolled-back data costs you money
Confirmed: The Sweet Spot
Confirmed commitment means the block containing your transaction has been voted on by validators representing at least 66% of the total stake. At this point, rolling back the block would require a supermajority of validators to switch their votes -- an event that has essentially never happened on Solana mainnet.
This is the default commitment level for most RPC methods, and for good reason. It provides strong guarantees with minimal additional latency compared to processed.
When to Use Confirmed
- Most dApp interactions -- swap confirmations, NFT mints, program interactions
- Trading bots that need to confirm fills before placing new orders
- Balance checks before initiating transactions
- Transaction confirmation for most non-high-value operations
The Practical Reality
For the vast majority of Solana development, confirmed is the right choice. It provides near-finality guarantees with latency that feels instant to users. Unless you have a specific reason to use processed or finalized, default to confirmed.
Finalized: Maximum Certainty
Finalized means the block has reached maximum lockout depth -- roughly 31 confirmation slots. At this point, the block is permanently part of the canonical chain. It cannot be rolled back under any circumstances short of a network-wide catastrophe.
The tradeoff is latency. Waiting for finalization adds several seconds compared to confirmed. On a network where most interactions feel instant, those seconds are noticeable.
When to Use Finalized
- Payment processing for high-value transactions (especially if you are releasing goods or services in exchange)
- Cross-chain bridges that need absolute certainty before minting wrapped assets on another chain
- Exchange deposits where crediting a user's account before finality creates risk
- Legal or compliance-sensitive operations where you need an immutable record
- Anchor program state reads where you are making irreversible decisions based on on-chain data
When Finalized Is Overkill
For most user-facing dApps, waiting for finalization creates a poor experience without meaningful risk reduction. If a user is swapping $50 of tokens on a DEX, the difference in rollback risk between confirmed and finalized is not worth the extra wait time.
How Commitment Levels Work in Code
When making RPC calls using @solana/web3.js, you specify the commitment level as a parameter.
Reading Account Data
// Fast but less certain
const processed = await connection.getAccountInfo(pubkey, "processed");
// Recommended default
const confirmed = await connection.getAccountInfo(pubkey, "confirmed");
// Maximum certainty
const finalized = await connection.getAccountInfo(pubkey, "finalized");
Confirming Transactions
// Wait for confirmed status (recommended for most use cases)
const confirmation = await connection.confirmTransaction(
{ signature, blockhash, lastValidBlockHeight },
"confirmed"
);
// Wait for finalized status (use for high-value operations)
const finalConfirmation = await connection.confirmTransaction(
{ signature, blockhash, lastValidBlockHeight },
"finalized"
);
Setting a Default
You can set the commitment level when creating the connection, so you do not have to specify it on every call:
const connection = new Connection(rpcUrl, {
commitment: "confirmed", // default for all calls
});
