Solana Commitment Levels: Processed vs Confirmed vs Finalized

The commitment ladder

Every read of Solana sits somewhere on a ladder of certainty. The higher you climb, the more sure you are that what you read will still be true in a second - and the longer you waited to know it.

The three named levels - processed, confirmed, finalized - are what the RPC and gRPC APIs let you ask for. First-seen-from-shreds isn't a commitment in the protocol sense; it's a vantage point below the bottom rung, which we'll come back to. The skill is knowing which rung a given decision belongs on.

Certainty and speed sit at opposite ends of the same ladder. The art isn't picking one - it's using the lowest rung you can tolerate for signal and the highest rung you can afford for settlement.

Processed: executed, maybe on a minority fork

processed means exactly one thing: a validator has executed the transaction and included it in a block at the tip of the chain it currently believes in. That's it. There has been no cluster-wide vote. The block you just read could be on a minority fork that loses out moments later, in which case the transaction effectively never happened.

This is the fastest of the three named levels because it asks for the least. You're reading a single node's freshest view, before consensus has had a chance to agree or disagree. For a strategy that wants the earliest committed state and can absorb the occasional reorg, that speed is the point. For anything where being wrong is expensive, processed is a trap dressed as a number.

Confirmed: supermajority voted

confirmed means a supermajority of stake - more than two-thirds - has voted for the block your transaction landed in. At that point a reorg isn't impossible, but it requires a large fraction of the network to have voted against the chain it just endorsed, which is rare and costly. For the overwhelming majority of applications, confirmed is the practical line between "probably true" and "true enough to act on."

It costs you a little latency over processed - you're waiting for votes to land - but you buy a large jump in certainty for it. This is why confirmed is the sane default for most reads and for sending transactions: it's fast enough to feel live and safe enough that you rarely have to think about forks.

Finalized: rooted and irreversible

finalized is the top of the ladder. The supermajority has not only voted for the block but rooted it, roughly 31 or more confirmations deep, and Solana now treats it as irreversible. There is no ordinary path by which a finalized transaction gets undone. If you've booked it as finalized, it's money-good.

The cost is latency: finality sits a few seconds behind the tip of the chain. That's invisible to a user checking a balance and unacceptable to a bot racing for an arbitrage. Use finalized wherever correctness must beat speed - accounting, settlement, user balances, anything you'd be embarrassed to reverse.

Below processed: first-seen from shreds

The three named levels all assume the transaction has at least been executed by some validator. You can read earlier than that. When a leader produces a block it doesn't broadcast it whole; it splits it into shreds, erasure-coded packets that propagate across the cluster through Turbine. Decode the data shreds for a slot and you can reconstruct the transactions while the block is still in flight - before any validator has executed it, and well before processed.

That's first-seen-from-shreds: the earliest observable moment of a transaction, sitting one notch below the bottom of the commitment ladder. It's the fastest read of Solana there is, and the least certain - a transaction you saw propagating can still land on a losing fork or a skipped slot and never finalize. The mechanics are in What Are Solana Shreds?, and the discipline for trading on it - react fast, settle on finality, bound the exposure in between - is in Reading Decoded Transactions Before Confirmation.

How to choose per use case

There's no single "right" commitment level - only the right level for a given decision. Map the job to the rung:

The strongest pipelines don't pick one rung - they layer several, each doing the job it's actually good at: shreds for first-seen signal, gRPC for live state at processed, and RPC for confirmed and finalized truth.

Setting commitment in code

Commitment is a parameter on almost every read. On a standard RPC client you pass it per call or set a default; on a streaming subscription you set it on the stream. The pattern is the same - you're telling the node how much certainty you want before it answers.

// a confirmed read: fast enough to feel live, safe enough to act on
const balance = await connection.getBalance(wallet, { commitment: "confirmed" });
 
// settlement read: wait for irreversibility before booking it
const tx = await connection.getTransaction(sig, { commitment: "finalized" });
 
// a live stream at processed - lowest committed latency
const stream = await rpcedge.subscribe({
  endpoint:   "grpc://iad1.rpcedge.com:443",
  source:     "geyser",
  commitment: "processed",
  filter:     { programs: [RAYDIUM, PUMP_FUN] },
});
 
for await (const update of stream) {
  signal.evaluate(update); // react now - reconcile against finalized later
}

For the rungs the commitment API can't reach, you go below it: rpc edge streams decoded shreds for first-seen signal and serves Yellowstone gRPC for live processed and confirmed state, so you can compose the exact mix of speed and certainty your strategy needs.

The takeaway

Commitment levels are a dial, not a default. processed is fast and provisional, confirmed is the practical line for most reads and writes, finalized is the only level you should ever call money-good - and first-seen-from-shreds sits below all of them when speed beats certainty. Pick the lowest rung you can tolerate for signal and the highest rung you can afford for settlement, and the ladder stops being a tradeoff you fight and becomes one you use.