Processed, Confirmed, Finalized
Transaction primitives
Solana exposes three commitment levels. Processed means the local validator saw the transaction and applied it to its fork. Confirmed means a supermajority has voted on the containing block. Finalized means at least 31 additional blocks have been built on top, which makes a rollback effectively impossible. You pick one per RPC call or stream subscription.
Detailed explanation
Processed is the freshest level. The validator you queried has executed the transaction and updated state. It is also the level most likely to be rolled back: if the leader for the slot loses its fork to the consensus winner, your "processed" view changes. For a sniper, that risk is acceptable. For settlement, it is not.
Confirmed sits in the middle. Two thirds of stake have voted on the block, so a rollback is unlikely but not impossible. Most application UIs use confirmed for transaction confirmations. The latency from processed to confirmed is typically 800 to 1500 milliseconds.
Finalized is the strongest level. By the time a block is finalized, 31 blocks have been built on top of it and a supermajority has voted at every step. The latency from processed to finalized is roughly 12 to 14 seconds. Custody, CEX deposits, and any path with real money use finalized.
Both RPC clients and Yellowstone gRPC subscriptions accept a commitment level. Setting it too loose risks rollback bugs. Setting it too tight adds latency you might not be able to afford. The right answer is per use case.
One opinion: bots that make trading decisions on processed and settle on finalized are doing it right. Bots that make settlement decisions on processed are gambling on no rollbacks ever happening, and they will be wrong eventually.
When you'll see this
Every Solana RPC method that touches state takes a commitment param: getAccountInfo, getTransaction, getSignatureStatuses, and so on. Yellowstone gRPC subscriptions take it on every filter. Watch transaction logs and you will see commitment levels propagated end to end.
How NoLimitNodes uses this
Our RPC and gRPC nodes honour all three commitment levels at the protocol level. Our Enhanced Streams tag every event with the commitment at which it was emitted so you can build downstream logic that respects rollback risk.
Related terms
- Yellowstone gRPC · The Triton-built Geyser plugin that exposes a gRPC stream of accounts, transactions, and slots over the wire.
- Geyser Plugin · A shared library a Solana validator loads to push account, slot, and transaction updates into your own pipeline.
- Compute Unit Budget · The CU limit and price you set with the ComputeBudget program to control how much work and priority fee a transaction uses.
- Durable Nonce · A System Program nonce account that lets a transaction stay valid past the 150-slot recent-blockhash window.
- Jito Tip · A SOL transfer to a Jito tip account that pays the block engine to include and order your transaction bundle.