Solana Commitment Levels Explained: Processed, Confirmed and Finalized
Commitment levels describe how sure the network is that a block will stay in the chain. processed is fastest and provisional, confirmed is the default, finalized is for anything irreversible. What each means, where it applies, and the bugs that come from mixing them.
Sourav Mishra · Solutions Engineer
Aug 23, 2026 • 10 min read
Solana Commitment Levels Explained: Processed, Confirmed and Finalized
When you build on Solana, you may encounter the terms processed, confirmed and finalized. These are what are known as the commitment levels.
Key Takeaways
- There is no single right choice when it comes to deciding which commitment level to use. Each situation is different, but there is usually a wrong choice for a given job.
- If you see unexpected behaviour such as transactions that are present one moment and gone the next, you may be using inconsistent commitment levels.
processedrefers to the node having executed the block that contains the transaction. It is the fastest option but the block may still be skipped over by the cluster.confirmedmeans that more than two thirds of the stake voted on the block. Rollback is highly unlikely.finalizedmeans the block has reached maximum lockout and cannot be rolled back.
What are commitment levels?
Commitment levels define how certain you can be that the state has become permanent. A commitment level is a way for us to communicate the degree of certainty that the transaction or the block will remain in the ledger.
Solana creates a block for every slot. This is currently 350ms on mainnet since the decrease from 400ms in August 2026.
When blocks are produced, they are only provisional, as the next leader(s) might choose to build on a different fork. Once more than two thirds of the stake has voted on that block during subsequent slots, the block becomes confirmed. Solana uses a consensus mechanism currently known as Tower BFT, where blocks become more solidified as further votes come in. Eventually, a block is finalized when it has reached maximum lockout and cannot be undone. This usually happens around 32 slots after the block was confirmed. At the current slot time that is somewhere between 11 and 13 seconds.
There is a consensus upgrade known as Alpenglow, which is designed to improve the finality time to around 150ms. The current release plan by Anza suggests it might be enabled on mainnet as soon as 28 September 2026, although Anza's schedules are tentative. Once that happens, the commitment levels will still apply, but the waiting time for finalized should be much shorter than it is today.
The three levels
It is worth noting that if you do not pass a commitment level, the RPC will use finalized by default. This is the safest option, but it is also the slowest. Many applications are waiting longer than they need to because of this default, without having made a decision about it.
Where commitment levels come up
As you use the RPC endpoints, you can see there are a few places where commitment levels come up.
Data requests
When you make reads, for example with getAccountInfo, getBalance or getTokenAccountBalance, you can pass in the commitment level. The same account may return a different value at each of the three levels. Each value is correct for its level. Similarly, when you subscribe to data, you can specify the commitment level. This applies to WebSocket subscriptions such as accountSubscribe and logsSubscribe, and to Yellowstone gRPC. A subscription at processed will give you events earliest, but some of those events may belong to a block that is later skipped.
Sending transactions
When using the sendTransaction method, you should keep the commitment level consistent within the flow. There is a preflightCommitment parameter which decides which state the simulation runs against. Solana's documentation says that this should always be the same commitment level that you used when fetching the blockhash. This applies to simulateTransaction as well. You might also be concerned about a particular piece of data changing between when you build the transaction and submit it. Reading that data at the same commitment level as the preflight helps to avoid this.
Fetching a blockhash
You can pass a commitment level to getLatestBlockhash as well. This matters more than you might expect. A blockhash is only valid for around 151 blocks, which is roughly 60 to 90 seconds. If you fetch the blockhash at finalized, it is already around 32 slots old when you receive it. This means you lose around 11 to 13 seconds of the time in which it is valid. For this reason, it is generally recommended to fetch the blockhash at confirmed.
Checking a transaction
When you check on a transaction, for example using signatureSubscribe or getSignatureStatuses, the response will tell you which commitment level the transaction has reached. A transaction that has landed at processed is not the same as a transaction that has landed at confirmed. It may still be skipped.
Which commitment level should I use?
The trading bot case is a little different from the others. There is a way to observe Solana that is earlier than any of the commitment levels. This is the shred broadcast from the leader, which happens before any node has processed the block. We have written about this in our shredstream article. Trading systems that need the earliest possible signal may use this, but they need to be able to handle the fact that some of the blocks they see will be skipped later on.
Common mistakes
Most of the problems people run into come from using different commitment levels in the same flow. Some examples are below.
The first is a balance that appears to change back. This can happen when one call is made at processed and another at finalized. The user sees one balance, then a different one. The solution is to make both calls at the same commitment level.
The second is a transaction that appears and then disappears. This happens when a transaction is seen at processed, the application acts on it, and then the block is skipped. It is safer to act on transactions at confirmed or later.
The third is an expired blockhash. This can happen when the blockhash was fetched at finalized. As explained above, the blockhash is older at this level, so it may expire before the transaction lands. Fetching at confirmed avoids this.
The fourth is a mismatch in preflight. This happens when the transaction is simulated against state that is different from the state it actually executes against, or when the preflight commitment does not match the blockhash commitment. Both should be aligned.
The fifth is an event that is later reverted. This can happen when a subscription at processed delivers an event, the application writes it to a database, and the block is then skipped. You may want to subscribe at confirmed instead, or implement rollback handling in the application.
Keeping it consistent
It is a good idea to decide on a commitment level for each part of your system and pass it explicitly. Relying on library defaults is not recommended, because the defaults vary between libraries and are often finalized. A common approach is to use confirmed for reads, finalized for settlement, and processed (or shreds) with rollback handling for anything that needs to be fast. It is also helpful to record the commitment level alongside each result, so that if two values disagree you can see why.
The commitment level is passed in the same way whether you are using JSON-RPC or Yellowstone gRPC, so the same considerations apply on the streaming side.
Conclusion
Commitment levels are how you choose between speed and certainty on Solana. processed is the fastest option but it is provisional. confirmed is the sensible default for most cases. finalized should be used for anything that cannot be undone. Set the level explicitly, keep it consistent within each flow, and remember that if you need to react faster than any commitment level allows, the leader's own broadcast is available before any node has processed the block.
OrbitFlare's RPC plans support every commitment level on every endpoint. The gRPC service streams at the commitment level of your choice, and Jetstream provides the view from before any commitment level exists.
Resources
FAQ
On the order of thirty slots after the block, which is roughly twelve seconds or more depending on network conditions. `confirmed` is reached much sooner, typically within a second.
For displaying and for most application logic, yes. For the final, irreversible step of releasing something of value, wait for `finalized`; the extra seconds are cheap insurance.
Most use `confirmed` for balances and transaction status, which is why a wallet shows a transaction as complete within about a second.
In theory, under extreme conditions; in practice it does not happen. The design treats `confirmed` as safe for everything except the truly irreversible.
Explorers typically show `confirmed` or `finalized`. A `processed` read reflects your node's newest, possibly not-yet-agreed state.
`processed` for the earliest RPC view, with logic that tolerates reverts, or a shred-derived feed for earlier still. Confirm fills at `confirmed` before updating positions.
Solana Commitment Levels Explained: Processed, Confirmed and Finalized
Related articles
Network Infrastructure for Low-Latency Solana Trading
Low-latency Solana trading infrastructure is four layers: placement relative to a leader that moves every four slots, how early you observe the chain, how you get transactions into a saturated leader, and how you route between regions. This guide explains each one and where the milliseconds go.
Fundamentalsp-token: How Solana Rewrote Its Most Important Program
Solana swapped in a new SPL Token program at the same address, and every transfer now costs about 60x less.
FundamentalsTop 10 Solana RPC Providers in 2026
Ranked breakdown of the ten Solana RPC providers worth considering in 2026, with a benchmarking checklist and a use-case-to-vendor map.