Solana Commitment Levels: Processed, Confirmed, Finalized

Your wallet just flashed a new balance. A swap UI said “success.” An explorer showed your signature in a slot. Then a minute later the number moved, or the fill you thought landed is gone from the view you trust. That usually isn't the chain “lying.” It's Solana commitment levels doing their job, and the app reading the newest, weakest view of the ledger.

Solana commitment levels are how an RPC node answers “how sure are we that this block sticks?” The three values you'll see in the docs are processed, confirmed, and finalized. I'll walk through what each means in plain words, why apps pick one over another, and what to check before you treat a balance or a fill as settled. Sources are the official RPC docs and the Solana Cookbook confirmation guide so you can check me.

What do Solana commitment levels actually mean?

Per Solana's RPC overview, many methods take a commitment parameter. It tells the node how finalized a block must be before it returns data or fires a notification. If you omit it, the default is typically finalized.

The getSlot commitment table spells out the same three levels with a bit more precision:

• processed: data from the highest slot this node has processed on the fork it currently thinks is best. Newest view. It can still change if the cluster switches forks.
• confirmed: data from the highest slot that at least two-thirds of active stake has directly voted to confirm. More stable than processed, weaker than finalized.
• finalized: data from the highest slot the cluster recognizes as finalized. In practice that means maximum vote lockout in validators' vote towers, recognized by at least two-thirds of active stake. Strongest level.

So commitment is not a fee setting and it's not “how fast your transaction is.” It's how far up the certainty ladder the node is allowed to read when it answers you.

Why does Solana need three levels?

Blocks can land on a fork that later loses. Until a slot has enough stake weight behind it—and eventually maximum lockout—the “latest” picture a single node sees can still roll back. Commitment levels exist so clients can choose: show progress fast, or wait until the cluster treats the state as locked in.

The Cookbook confirmation guide puts the practical tradeoff on blockhashes (the same ladder applies to reads):

• Prefer confirmed for most RPC work. It's usually only a few slots behind processed, with a very low chance the block belongs to a dropped fork.
• processed is freshest, with more rollback risk. It gives the newest blockhash and the most time before expiration, but the guide notes that roughly 5% of blocks don't end up finalized, so a blockhash from a dropped fork can strand a transaction.
• Default finalized removes that fork risk. There's typically at least a 32-slot gap between the latest confirmed and latest finalized block—about 13 seconds of expiration headroom lost under normal conditions, and more when the cluster is messy.

Speed versus certainty. Same ladder, different rung.

What should wallets, RPC clients, and apps actually do?

If you're building—or just trying to read what a tool is showing you—commitment is one of the quiet settings that decides whether the UI is optimistic or conservative:

• UI progress can be processed or confirmed. Showing “seen by our node” or “voted by a supermajority” is fine as progress. Treat it as provisional until you know which commitment the client used.
• Money-moving decisions want higher commitment. Before you assume a deposit landed, a swap settled, or a balance is spendable for the next hop, prefer confirmed at minimum and finalized when the cost of a rollback is real (bridging, custody handoffs, anything you can't cheaply retry).
• Match preflight to the blockhash you fetched. The Cookbook's common footgun: fetch a recent blockhash at one commitment, then sendTransaction / simulateTransaction with a different preflightCommitment (or a lagging RPC). Set preflight to the same level you used for the blockhash, even if you skip preflight simulation.
• Don't trust one lagging RPC for “latest.” Nodes can trail the cluster. The guide's baseline is to watch slot health or compare getLatestBlockhash at confirmed across a few endpoints and keep the freshest healthy response.
• Expiration is short. Recent blockhashes stay valid for about 151 blocks (roughly 60–90 seconds at typical slot times). Commitment choice eats into that window. Pair this with how you set fees in priority fees and compute units—a perfect fee still fails if the blockhash aged out on a weak fork.

For trench users who aren't writing RPC clients: if a wallet or bot flashes a fill and the explorer view at finalized still doesn't show it, wait a beat and refresh at a higher commitment before you ape the next size. Same idea when a “reclaim” or cleanup tool shows SOL moving—read the preview, and remember empty token account rent deposits only come back when the close actually lands and sticks.

What this doesn't cover

Commitment is about ledger certainty, not about whether a pool can absorb your size, whether an authority can mint, or whether an RPC is honest. A finalized read of a thin pool is still a thin pool. A confirmed balance in a compromised UI is still whatever that UI chose to show.

I also haven't named a specific wallet, bot, or RPC vendor here. Implementations differ on which commitment they use for balance chips, toast notifications, and explorer links. When it matters, check their docs or the request your client is actually sending. Cluster conditions change the gap between confirmed and finalized; the “about 13 seconds / 32 slots” figure is the Cookbook's typical case, not a constant.

Durable nonces, skipped slots, and full fork-choice internals are deeper topics. This piece is the commitment rung only.

The takeaway

Solana commitment levels—processed, confirmed, finalized—are a speed-versus-certainty ladder for reads and for the blockhashes your transactions ride on. Newest is not the same as locked in. For most app RPC, confirmed is the Cookbook's default recommendation; use finalized when a rollback would hurt, and never mix a fresh blockhash with a mismatched preflight. Before you trust a balance or a fill, ask which commitment that screen used. More plain-words walkthroughs live in the guides. When your wallet flashes “success,” do you wait for confirmed or finalized before you treat the bag as real?

Still building. Still here. 🫡