An exchange support page says your Solana deposit needs “a few confirmations”. A wallet shows a green tick after about a second. Your own explorer tab says “confirmed”, then, a while later, “finalized”. None of those three is using the word the same way, and none of them says what it counted.
Solana’s commitment levels are not a count of blocks the way Bitcoin’s are. Two of them are measurements of stake, and the third is a depth. This post is what each one measures, read from the validator and the reference client, and the one deadline in the client that decides when it gives up.
Processed, confirmed, finalized: what each one is
A transaction has three states the network will report.
- Processed means one node executed it in a block that node built or replayed. Nothing else has agreed. The block can still be abandoned, and a transaction can be “processed” and never land.
- Confirmed means the block reached optimistic confirmation: more than two-thirds of the epoch’s stake has voted for it. The validator stores this as an array of 32 buckets of stake, one per lockout depth, and “confirmed” is the lowest depth at which more than two-thirds is locked out. That is a one-vote-deep supermajority. It is also the level at which a wallet turns the tick green.
- Finalized means the block is rooted — the validator’s tower has 32 votes stacked on top of it, the maximum lockout history plus one. At that depth a validator can no longer vote for a competing fork without forfeiting its stake, and the reference client treats it as irreversible.
Worth knowing: the two-thirds number is a stake fraction, not a validator count. Two hundred small validators voting is not “confirmed”; three large ones might be.
How long each one takes, in today’s slots
Confirmed arrives when enough stake has voted once, which in practice is a handful of slots. Finalized arrives when 32 blocks have been built on top, which is 32 slots on a healthy chain.
At the 250 ms slot time in force when this was written, 32 slots is 8 seconds. The 200 ms step activated this morning and takes effect next epoch, after which it is 6.4 seconds. Under the original 400 ms slot it was 12.8 seconds, which is where most “about fifteen seconds” rules of thumb came from.
Those are the best cases. A skipped leader adds its window. A fork adds the time to resolve it. And the reference client has a hard stop: if a transaction has not finalized within 120 seconds, the client gives up and reports that it may have landed on an abandoned fork.
The query that answers it for one block
getBlockCommitment returns the 32-bucket stake array and the total stake for a slot. The sum of buckets at depth d and deeper is how much stake has that block at least d votes deep. Divide by total stake and you have a number, not a word.
Two limits on it. The node only keeps commitment for slots between its root and its tip, so a block that has already been rooted returns nothing — it is final; the array is gone. And the array is that node’s view: a node a few slots behind reports less stake than one at the tip.
For a signature rather than a block, getSignatureStatuses reports confirmations as a count up to 31, and null once the block is rooted. Null does not mean unknown. It means finalized.
Crediting a deposit: a rule that does not pretend
If you credit on “confirmed”, you credit on two-thirds of stake having voted once. That has not been reorganised in practice, but it is one vote deep and the protocol does not promise it. If you credit on “finalized”, you wait 32 slots and get the protocol’s own definition of irreversible.
For small amounts the difference is a few seconds; for large ones it is the difference between a measurement and a promise. The honest rule is to credit on confirmed for display and on finalized for release, and to use the stake array rather than the word when the amount justifies a query.
One more thing the word hides: a transaction that never landed also never confirms, and the client will tell you nothing until its blockhash expires — 150 slots, 37.5 seconds at 250 ms and 30 seconds at 200 ms. A deposit that is “pending” past that window is not slow. It is gone, and the reasons are a separate post.
What Alpenglow replaces
Everything above is the tower-voting model. Alpenglow, active on testnet and devnet and not yet queued on mainnet when this was written, replaces vote depth with certificates: a block is final when 60% of stake has signed a finalize certificate after notarizing it, or when 80% notarizes in one round. There is no 32-block depth to wait for, and “confirmed” versus “finalized” collapses toward one event.
Until the mainnet gate activates, the model in this post is the one in force. After it, the right question is “does a finalize certificate exist”, and the numbers are in the Alpenglow post.
Confirmations: Questions People Actually Ask
How many confirmations does Solana need to be final?
Thirty-two. “Finalized” means 32 blocks have been built on top of the one holding your transaction, which is about 8 seconds at 250 ms slots and 6.4 seconds at 200 ms.
What does “confirmed” mean on Solana?
More than two-thirds of the epoch’s stake has voted for the block at least once. It is a stake measurement, one vote deep, and it is the level most wallets show as a green tick.
Why does getSignatureStatuses show confirmations as null?
Because the block has been rooted. Null is the finalized state, not an unknown; counts from 1 to 31 appear only while the block is still accumulating depth.
How long should an exchange wait before crediting a Solana deposit?
Display on confirmed and release on finalized. If a deposit has not confirmed within the blockhash lifetime of 150 slots, it did not land and will not.
The three numbers
Two-thirds of stake, voting once — that is “confirmed”, and it is what the green tick means.
Thirty-two blocks deep — that is “finalized”, 8 seconds today and 6.4 next epoch.
One hundred and twenty seconds — that is when the reference client stops waiting.
Credit on the second, display on the first, and treat the third as the point at which something has gone wrong rather than slow.
— The Number Moves With the Slot Time —
Confirmation times are slot counts times a slot length that keeps changing.
The upgrades tracker reads the slot-time and Alpenglow gates from the chain every minute, so the seconds you quote match the regime actually in force.
The replacement for all of this is a certificate rather than a depth — Alpenglow finality in numbers — and the transaction that never confirms at all is a drop with no error. Every second-count above moves with the slot-time ladder.
Constants read from the Agave validator source at commit beee69b958: runtime/src/commitment.rs and rpc-client/src/nonblocking/rpc_client.rs. Slot times and gate states were read from mainnet on 8 October 2026, epoch 1052.