Why confirmed means different things on different chains
Probabilistic depth, economic finality and per-block agreement are three different promises, and confirmation counts are institutions translating them.
Confirmed is a policy word, not a protocol word. Different networks make different promises about when a recorded transaction can no longer be undone, and those promises range from a probability that decays with each new block to a mathematical guarantee backed by capital that will be destroyed if it is broken. The number of confirmations an exchange or a wallet waits for is that institution's translation of the underlying promise into an operating rule.
Probabilistic settlement
Under proof of work there is no moment at which a block becomes permanent. Nodes follow the chain with the most cumulative work, so a transaction is reversed if someone builds a longer competing branch that excludes it. The probability of that happening falls roughly exponentially with the number of blocks built on top, given an attacker who controls less than half of hash power, and it never reaches zero. Six confirmations became a convention because it drives that probability very low for a modest attacker at typical block times, not because the protocol defines anything at six.
Two consequences follow. First, depth is the safety parameter, and depth is measured in blocks rather than minutes, so block time determines how long a given level of assurance takes. Second, the appropriate depth depends on value: the honest question is whether the cost of producing a competing branch exceeds what reversing the transaction would be worth to the attacker, which is why large settlements are treated differently from small ones.
Economic finality
Modern proof of stake designs add an explicit finalization step. Validators do not merely build; they vote, and once a two-thirds supermajority of staked capital has attested to a checkpoint, the protocol treats it as final. Reverting it would require at least a third of all staked capital to have signed contradictory attestations, and that contradiction is exactly what slashing punishes. So the guarantee is not that reversal is impossible; it is that reversal has a known, enormous, automatically enforced price. Ethereum finalizes at epoch boundaries, which puts finality on the order of a quarter of an hour after inclusion, while individual blocks are usually stable much sooner.
The awkward caveat is that finality applies to the checkpoint, not to the last few blocks. A transaction included in the current slot has been ordered, but it has not yet been finalized, and the two states get reported to users under the same word.
Instant finality, and what it costs
A third family runs a classical Byzantine agreement round for every block. A proposed block is final once a two-thirds supermajority of validators signs it, typically within a second or two, and no reorganization of a signed block is possible without those signatures existing in public. The price is liveness: if the supermajority cannot be assembled — because validators are offline, partitioned, or disagreeing — the chain stops producing blocks rather than producing a branch that might later be undone. Chains in this family have halted in practice, and a halt is a failure mode with its own operational consequences.
This is the classic tradeoff stated concretely. A chain can prefer to keep going and let history occasionally be revised, or prefer never to revise and occasionally stop. Neither preference is a defect, but they produce very different operational risks.
| Design family | What final means | How reversal happens | Failure mode |
|---|---|---|---|
| Longest-chain proof of work | Probability of reversal decays with depth, never reaching zero | Someone outbuilds the chain from an earlier point | Deep reorganization by majority hash power |
| Checkpoint proof of stake | Finalized checkpoints cannot be reverted without slashable votes | At least a third of stake signs contradictory attestations | Delayed finality when participation drops |
| Byzantine agreement per block | Each signed block is final immediately | Effectively not, without a supermajority collusion | Chain halts when the supermajority is unavailable |
Why intermediaries pick their own confirmation counts
An exchange crediting a deposit is deciding how much of someone else's reversal risk to absorb. Its confirmation policy therefore reflects value at risk, the cost of attacking that particular chain, and how quickly it wants to serve customers, which is why the same institution waits different numbers of blocks on different networks and sometimes different numbers for different amounts. A chain with a small security budget relative to the value moving over it may warrant very deep confirmation even though its block times are fast, and this is a place where fast blocks are routinely mistaken for fast settlement.
The related distinction is between inclusion and settlement. A transaction sitting in the mempool is not confirmed at all; a transaction in the newest block is included but revisable; a transaction below the depth an institution accepts is settled as far as that institution is concerned. Three states, often described with one word.
Finality for bridges and layer 2s
Systems built on top of a chain inherit its finality properties and sometimes add their own delays. A bridge that mints a representation on one chain after seeing a deposit on another must decide how deep to wait, and several historical incidents involved acting on insufficiently settled information. A layer 2 introduces a second clock entirely: an optimistic rollup gives users fast confirmation from its sequencer, then a challenge window of days before withdrawals settle on the base chain. A user can be confirmed on the rollup, unconfirmed for withdrawal purposes, and both statements are correct.
When comparing networks, treat block time and finality as separate columns rather than one. Read block time alongside validator counts on the comparison tool, and see incidents for cases where settlement assumptions failed in practice.