Finality and Confirmations: When Is It Settled?

“Confirmed” means different things on different chains, and the difference matters whenever value changes hands. A transaction included in a block has happened in one sense and can still be undone in another. Finality is the question of when that stops being true.

Two Models

Settlement by accumulated work. A chain that selects the history with the most work behind it never declares a transaction final. It becomes progressively more expensive to reverse as blocks accumulate on top, because reversing it means producing an alternative history that outpaces the one everyone else is extending.

This is probabilistic finality. The probability of reversal falls sharply with depth and never reaches zero.

Explicit finality. A chain where validators vote on checkpoints can declare a point beyond which reversal is not merely expensive but requires validators to have violated the rules in a way that carries a penalty. Reversal is possible only by breaking the protocol’s economic guarantees rather than by outcompeting it.

This is deterministic finality, with the caveat that it depends on enough validators participating. A chain unable to reach the required agreement continues producing blocks without finalising them.

What a Reorg Undoes

Two valid blocks can be produced at nearly the same time, and different parts of the network see them in different orders. Briefly, there are two versions of recent history.

The rules select one. Nodes that had adopted the other switch, and the blocks they abandon are discarded.

Transactions in those discarded blocks are not destroyed. They return to pending and are usually included again in a subsequent block. But they may be included in a different order, and if a conflicting transaction made it into the surviving chain first, the original may become invalid and never confirm.

Short reorgs of a block or two are a normal occurrence on some chains. Deep ones are rare and significant.

Why Confirmation Counts Differ

An exchange choosing how long to wait before crediting a deposit is making a risk judgement about a specific chain.

The relevant factors are how quickly blocks are produced, how much security sits behind each one, how often short reorgs occur in practice, and how much value is at stake. A chain with fast blocks and less accumulated security needs more of them to reach comparable confidence than a chain with slow, heavily secured blocks.

That is why published requirements vary widely by asset, and why a number remembered from one chain is meaningless on another. The count is not a property of the transaction; it is a policy about a particular chain.

What This Means in Practice

For small amounts between parties who trust each other, inclusion in a block is usually treated as sufficient.

For larger amounts, or between parties who do not know each other, depth matters and waiting is cheap relative to the exposure.

For anything irreversible in the physical world, such as handing over goods, the appropriate wait is longer than feels comfortable, because the reversal risk is entirely on the party who gave up something real.

On chains with explicit finality, waiting for finalisation rather than for a block count is the meaningful threshold, and it is usually not long.

Layer Two and Settlement

Transactions on a layer two system are confirmed by that system quickly, and then settled on the underlying chain on a different schedule.

The two are separate events with separate risk profiles. A transaction confirmed on the layer two but not yet settled depends on that system’s own guarantees, which vary by design. Withdrawal periods on some designs exist precisely because the settlement guarantee takes time to mature.

See layer 2 for how the designs differ, because the finality question is answered differently by each.

What People Get Wrong About This

The first mistake is treating inclusion in a block as settlement. It is the first step toward it.

The second is carrying a confirmation count from one chain to another. The number reflects that chain’s block time and security, not a universal standard.

A third is panicking when a transaction disappears after a reorg. It has usually returned to pending and will be included again.

A fourth is assuming explicit finality means nothing can ever go wrong. It means reversal requires rule violations that carry penalties, which is a strong guarantee resting on assumptions about participation.

And the last is waiting for confirmations on a transaction that was never broadcast successfully or is stuck behind an earlier one. That is a different problem; see stuck transactions and nonce and transaction order.

The Practical Summary

Inclusion is not settlement. Depth buys confidence on chains that settle by work. Finalisation is the threshold on chains that provide it. And the right amount of waiting is set by what you would lose if the transaction were reversed, not by a number someone quoted for a different chain.