Optimistic Confirmation vs Finality
The previous page, Fork Choice — Picking the Heaviest Fork, showed how a validator, presented with competing forks, picks the one carrying the most stake-weighted votes. That is how the network converges on one history. This page answers the question that converging leaves open: once your transaction lands in a block on that winning fork, when can you trust it? When is it safe to ship the goods, credit the account, or let the withdrawal through?
Solana gives you two answers, not one — two guarantees with two different strengths and two different latencies. Optimistic confirmation arrives fast: a supermajority of stake has voted for your block, so reversing it would be enormously expensive. Rooted finality arrives slower: the block is buried so deep under confirming votes that no honest validator’s rules will ever let them roll back to before it. Knowing the difference — and knowing which one a given payment deserves to wait for — is the whole job of this page. It is the same instinct a Bitcoin user has when they wait for confirmations, adapted to a chain where the clock ticks in hundreds of milliseconds rather than minutes.
Two guarantees, not one
Section titled “Two guarantees, not one”Every chain has to answer “is this settled?” and every honest chain admits the answer is a gradient, not a switch. A block that just appeared could still lose a fork race. A block a thousand blocks deep is, for all practical purposes, permanent. Between those extremes the confidence rises continuously. Solana names two useful points on that gradient and gives each a precise meaning:
your transaction's life after it lands in a block
included ──► optimistically confirmed ──► rooted / finalized (in a block (>2/3 of stake has voted (lockout maxed out; buried on some for it; reverting needs so deep no honest node can fork) a slashable supermajority roll back — durable) reversal — fast)
time: ~one slot well under a second many slots later to a few seconds (~tens of slots of confirming votes)The two points are not competitors. Optimistic confirmation is the early read — strong enough for most uses, delivered fast. Rooting is the final read — the guarantee you lean on when the stakes are high enough that “very likely permanent” is not good enough and you want “permanent by the protocol’s own rules.” A well-built application chooses a threshold per transaction, exactly as an exchange chooses how many Bitcoin confirmations to require before crediting a deposit.
Optimistic confirmation — the fast read
Section titled “Optimistic confirmation — the fast read”Recall from Stake-Weighted Voting that validators vote on blocks and each vote carries weight proportional to the validator’s stake. Optimistic confirmation is the moment when blocks holding your transaction have collected votes from more than two-thirds of the total staked supply — a supermajority.
Why is a two-thirds supermajority the magic threshold? Because it is the classic Byzantine-fault-tolerant bound. As long as strictly more than two-thirds of stake is honest, at most just-under one-third is malicious, and no two conflicting blocks can each collect a two-thirds supermajority without some stake voting for both sides of the conflict — which is precisely the thing the protocol punishes. So once your block has crossed two-thirds, an attacker who wants to reverse it must convince a supermajority to abandon it and confirm a competing block, and that requires validators to cast contradictory votes.
why >2/3 confirmation is hard to reverse
total stake = 100 units, need >66.6 to confirm
fork A confirmed: [ 67 units voted A ] ──────────────── to reverse, fork B [ 67 units voted B ] ──────────────── needs also: overlap ≥ 34 units voted BOTH A and B │ └─► that overlap is provably equivocation → slashableThat overlap is the key. To confirm two conflicting forks you need the same large block of stake to have voted for both, and voting for two conflicting blocks at the same height is equivocation — an offense the protocol can prove from the two signed votes alone and punish by slashing the offender’s stake. So the strength of an optimistic confirmation is not a vague probability; it is measured in slashable stake: reverting a confirmed block would force at least a third of all staked value to sign its own death warrant.
That is why “optimistic” is the right word. It is not a full protocol-level finality proof — it is a bet, but a bet backed by an amount of money so large that no rational, self-interested majority would take the other side. Fast, and very safe, but not the maximal guarantee the chain can offer.
How fast is fast?
Section titled “How fast is fast?”Solana produces a block roughly every few hundred milliseconds, and votes for a block are themselves transactions that land in following blocks. So a supermajority of votes accumulates within a small number of slots after your block is produced — in practice well under a second to a few seconds under healthy conditions. That is the number people mean when they call Solana “fast to confirm”: not that the block exists quickly, but that the supermajority agreement on it exists quickly. Compare Bitcoin, where a single confirmation is a ~10-minute block and cautious settlement waits for six of them (~an hour).
Finality — the durable read
Section titled “Finality — the durable read”Optimistic confirmation says a supermajority has voted for your block right now. Rooting (also called reaching maximum lockout, or finalization) says something stronger and more permanent: the block is buried so deep, under so many confirming votes, that the consensus rules themselves forbid any honest validator from ever rolling back to before it.
The mechanism comes straight from Tower BFT and Exponential Lockouts. Recall that when a validator votes for a block, it commits to a lockout — a promise not to vote for a conflicting fork for some number of slots — and each additional confirming vote doubles that lockout. A block is rooted when a vote’s lockout reaches the maximum depth in the tower (Solana’s tower is 32 votes deep, so the deepest lockout is 2³² slots — astronomically long). At that point the vote at the bottom of the tower is committed forever: no honest validator running the protocol can ever legally switch away from that block, because doing so would violate a lockout it already signed.
a validator's tower fills from the top; roots fall off the bottom
vote # lockout (slots) newest vote (small lockout, still flexible) ┌──────────────────────┐ │ #1 2^1 = 2 │ ◄─ just voted; could still be abandoned │ #2 2^2 = 4 │ │ #3 2^3 = 8 │ │ … │ │ #31 2^31 ≈ 2.1e9 │ │ #32 2^32 ≈ 4.3e9 │ ◄─ lockout maxed → this block ROOTS → finalized └──────────────────────┘ as new votes push in on top, the maxed-out vote at the bottom becomes a permanent ROOT — the block below it can never revertA rooted block is final in the strongest sense the protocol offers. Optimistic confirmation says reverting this would cost an attacker a slashable fortune; rooting says reverting this would require honest validators to break rules they have already cryptographically committed to. The first is an economic argument; the second is a protocol-rules argument. Both are strong; rooting is the one you cannot walk back.
How slow is slow?
Section titled “How slow is slow?”Because rooting requires a vote’s lockout to climb all the way to the top of a 32-deep tower, it needs a long, uninterrupted run of confirming votes stacking on top of your block. That takes meaningfully longer than a single supermajority snapshot — on the order of tens of slots of accumulated voting in practice (the tower fills once a supermajority has cast roughly 32 subsequent votes), i.e. seconds into the tens-of-seconds range rather than sub-second. The exact wall-clock number depends on network health and load; treat “confirmation in under a second or few, full rooting notably longer” as the durable shape, not a benchmark.
Which one should you wait for?
Section titled “Which one should you wait for?”This is the practical payoff, and it is the same discipline a Bitcoin exchange applies with confirmations: match the depth of confirmation to the value at stake and the cost of being wrong.
pick a threshold by what a reversal would cost you
value / reversibility wait for ────────────────────────────── ────────────────────────────── a like, a low-value UI update inclusion is often fine a normal payment / swap optimistic confirmation (>2/3 votes) a high-value settlement, rooted / finalized (max lockout) — an irreversible off-chain the durable guarantee payout, a bridge withdrawalMost user-facing actions are safe at optimistic confirmation: the reversal cost is a slashable
supermajority, so the practical risk is negligible and you get sub-second-to-few-second settlement.
But anything where a reversal would be catastrophic and irreversible on your side — releasing funds
across a bridge, paying out fiat against a deposit, settling a large trade with no recourse — should wait
for rooting, because that is the point where the guarantee stops being “extremely expensive to break”
and becomes “the protocol’s own rules forbid it.” The extra seconds are cheap insurance against the tail
risk. Chains publish these states so that clients can subscribe to a commitment level
(processed → confirmed → finalized) and gate their own logic on it.
The honest caveat — the guarantees are dated and load-dependent
Section titled “The honest caveat — the guarantees are dated and load-dependent”Everything above assumes the network is behaving: votes flow, blocks land, the supermajority is honest and online. That assumption is exactly what Solana’s history warns you to hold loosely.
First, optimistic confirmation is a safety property that can, in principle, be violated — under an extreme validator collusion (a supermajority equivocating and accepting the slashing) or a consensus bug that lets contradictory votes both count. It is very strong, not absolute. Rooting is stronger, but it too rests on the tower rules being implemented correctly across the whole validator set.
Second, and more concretely, the guarantees are load-dependent. As the sibling foundations page What “Hardware Speed” Means laid out, a maximally tuned single chain has little slack, and Solana’s failures have overwhelmingly been liveness failures — the network halting — rather than safety failures — the network reversing a confirmed transaction. That distinction is the point of this whole page: a halt means your confirmation stops advancing toward rooting for a while; it does not mean a rooted transaction got un-rooted.
The architect’s lens
Section titled “The architect’s lens”- Why does it exist? Because “is my transaction settled?” is a gradient, not a yes/no, and users need named, meaningful points on that gradient. Optimistic confirmation exists to give a fast trustworthy answer; rooting exists to give a maximally durable one.
- What problem does it solve? It lets an application choose its own safety/latency trade-off per transaction — settle a low-value swap in under a second on confirmation, but hold a bridge withdrawal for rooting — instead of forcing every use to pay for the strongest guarantee.
- What are the trade-offs? Confirmation is fast but economic (reversal is very expensive, not impossible); rooting is protocol-final but slower. Waiting for rooting on everything wastes Solana’s speed advantage; trusting confirmation for everything exposes catastrophic, irreversible payouts to a tail risk.
- When should I avoid it? Don’t rely on optimistic confirmation (or worse, mere inclusion) for actions
you cannot undo and cannot afford to lose — cross-chain releases, fiat payouts, large final settlements.
Those should wait for
finalized. - What breaks if I remove it? Drop the distinction and you either make everyone wait for full finality (throwing away the sub-second confirmation that is a core selling point) or let everyone trust the weakest state (inviting a reversal to steal an irreversible payout). The two-tier model is what lets one chain serve both a payment and a bank wire.
Check your understanding
Section titled “Check your understanding”- State the two guarantees this page defines, and give the one-line difference between them — one is an economic argument and one is a protocol-rules argument.
- Why is a two-thirds supermajority the threshold for optimistic confirmation? Walk through why reversing a confirmed block forces some stake to equivocate, and what happens to that stake.
- What does it mean to say a confirmation’s strength is “measured in slashable stake” rather than in a probability? Use the overlap argument.
- Explain how rooting works in terms of the tower and exponential lockouts. Why can no honest validator roll back a rooted block?
- Give the rule for choosing which guarantee to wait for, and explain, using Solana’s outage history, why the practical risk has been “confirmation may stall” rather than “finalized history may rewind.”
Show answers
- Optimistic confirmation: more than two-thirds of staked value has voted for your block, so reversing it is enormously expensive — an economic argument (reversal would require a slashable supermajority). Rooted finality: the block’s vote lockout has reached maximum depth in the tower, so the consensus rules forbid any honest validator from rolling back to before it — a protocol-rules argument. The first says “reverting costs a fortune”; the second says “reverting breaks rules already signed.”
- Two-thirds is the Byzantine-fault-tolerant bound: if more than two-thirds of stake is honest, no two conflicting blocks can each gather a two-thirds supermajority without some stake voting for both. To reverse a confirmed block, an attacker needs a supermajority to confirm a competing fork, which forces an overlapping ~one-third of stake to have voted for two conflicting blocks. That is equivocation, provable from the two signed votes, and it gets that stake slashed (destroyed).
- Because the barrier to reversal isn’t “it’s unlikely” — it’s a concrete, provable financial penalty. To confirm two conflicting forks, the same large block of stake (about a third of all stake) must have voted for both, and that double-vote is provable equivocation that gets slashed. So the confirmation’s strength is the amount of stake that would be destroyed to break it — an economic quantity you can price, not a fuzzy probability.
- Every vote commits to a lockout (a promise not to vote a conflicting fork for some slots), and each confirming vote stacked on top doubles it. A block is rooted when a vote’s lockout reaches the maximum tower depth (2³² slots, at the bottom of the 32-deep tower). At that point an honest validator has already signed a lockout that would be violated by switching away, so its own rules forbid rolling back — the root is permanent by construction, not just by cost.
- Rule: match the depth of confirmation to the value and irreversibility at stake — inclusion for
trivial UI, optimistic confirmation for ordinary payments/swaps, and rooting/
finalizedfor high-value, irreversible settlement (bridge withdrawals, fiat payouts, large final trades). Solana’s real-world failures (the 14 September 2021 halt and later outages) were liveness failures — the chain halted and restarted — with no widely reported reversal of a rooted transaction, i.e. no safety failure. So the observed risk is that confirmation stalls under load, not that finalized history rewinds; waiting for rooting on irreversible actions defends against the tail case regardless.