Finality is the guarantee that a block, and the transactions in it, can no longer be reverted once the network has agreed on it. In consensus mechanisms it answers a practical question every exchange, merchant and bridge must ask: from which moment is a payment truly settled?
Different blockchains reach finality in very different ways. Proof of work chains offer probabilistic finality that grows stronger with each new block, while many proof of stake and Byzantine fault tolerant systems provide deterministic finality, where a block is irreversible once a supermajority of validators has signed it.
How finality is reached
In a blockchain, several valid versions of recent history can briefly coexist, for example when two miners find a block at almost the same moment. Forks of this kind are resolved by the fork choice rule. Finality describes the point at which the network has committed to one version so firmly that switching to another is impossible or prohibitively expensive.
Under Nakamoto consensus, used by Bitcoin, nodes follow the chain with the most accumulated work. Each additional block on top of a transaction, called a confirmation, makes reversal exponentially less likely, because an attacker would need to redo all that work faster than the honest network. Finality is never absolute, but the probability of reversal becomes negligible.
Under BFT-style consensus, a known set of validators votes on each block. Once more than two thirds of the voting power has signed, the block is final immediately. Reverting it would require a large share of validators to sign conflicting blocks, which protocols detect and punish through slashing.
Types of finality
Practitioners distinguish several kinds of finality, because the guarantee behind each one is different. The table summarizes the main types and where they appear.
| Type | Guarantee | Typical consensus |
|---|---|---|
| Probabilistic finality | Reversal becomes exponentially unlikely with depth | Proof of work, Nakamoto consensus |
| Deterministic finality | Block cannot be reverted once committed | BFT protocols such as Tendermint-style designs |
| Economic finality | Reverting would destroy a large amount of stake | Proof of stake with slashing |
| Checkpoint finality | Periodic checkpoints become irreversible | Finality gadgets on proof of stake chains |
| Optimistic confirmation | Strong signal before formal finality | High-throughput chains |
Economic finality is the most common framing for modern proof of stake. It does not claim reversal is mathematically impossible, but that it would require validators controlling at least one third of the total stake to violate protocol rules and lose that stake.
Finality also differs in how it is observed. With probabilistic finality, each application chooses its own confirmation threshold. With deterministic or checkpoint finality, the protocol itself marks blocks as finalized, and node software exposes that status directly, so applications can query it instead of counting blocks.
Time to finality across networks
Time to finality is the delay between submitting a transaction and reaching the level of finality a recipient requires. It depends on block time, the voting process and the risk tolerance of the recipient, so the figures below are typical orders of magnitude rather than fixed values.
| Network design | Finality model | Typical time to finality |
|---|---|---|
| Bitcoin | Probabilistic, often six confirmations | About one hour |
| Ethereum proof of stake | Checkpoint finality after two epochs | About 13 minutes |
| BFT chains with single-slot finality | Deterministic per block | A few seconds |
| Layer 2 rollups | Depends on settlement to layer 1 | Minutes to days, by design |
| Permissioned blockchains | Deterministic among known members | Sub-second to seconds |
For rollups, the distinction between soft confirmation by the sequencer and final settlement on layer 1 matters greatly. Optimistic rollups add a challenge window, commonly around seven days, before withdrawals to layer 1 are considered final.
Finality and the trade-offs of consensus design
Fast deterministic finality comes at a price. BFT protocols require communication among all validators for each block, which limits how many validators can participate and pushes designs toward smaller validator sets. Probabilistic systems scale to open participation more easily but settle more slowly.
Another trade-off concerns liveness versus safety. When too many validators go offline, a BFT chain may stop producing final blocks to remain safe, while a Nakamoto-style chain keeps producing blocks but with weaker guarantees. Some designs, including Ethereum, combine both: blocks are produced continuously, and a separate finality gadget finalizes checkpoints when enough validators participate.
The table below contrasts how the two broad families behave when the network is under stress, which is when the difference between safety and liveness becomes visible.
| Situation | Probabilistic finality | Deterministic finality |
|---|---|---|
| Many validators offline | Blocks continue, confirmations slower | Finalization pauses until quorum returns |
| Network partition | Competing chains grow, one later wins | No conflicting final blocks, progress may halt |
| Attacker with large resources | Can attempt a deep reorganization | Must control at least one third of stake to stall or two thirds to finalize conflicts |
| Recovery after the incident | Longest or heaviest chain prevails | Social coordination or slashing may be needed |
Practical consequences and common mistakes
For exchanges, payment processors and cross-chain bridges, finality determines when funds can safely be released. Crediting a deposit too early exposes the service to double-spending if the chain reorganizes. Many incidents involving bridges and exchanges have been linked to treating unfinalized blocks as settled.
- Confusing inclusion with finality: a transaction in a block is not yet final.
- Using one confirmation count for every chain: requirements depend on hash rate, stake and value at risk.
- Ignoring deep reorganizations on smaller proof of work chains with low hash rate.
- Treating rollup soft confirmations as layer 1 finality when moving large amounts.
- Not adjusting thresholds to transaction value, since larger transfers justify waiting longer.
The simple explanation
Finality is the moment a blockchain payment becomes permanent. Before that point, the network could still reorganize recent records. After it, nobody can undo the payment.
Think of wet concrete. Right after it is poured, you can still draw in it. A few hours later it has set, and changing it would take a jackhammer. Some blockchains set almost instantly. Others harden gradually, block by block. Knowing when the concrete has set tells you when to trust a payment.
How it is used in practice
A cryptocurrency exchange accepts deposits on several networks and must decide when to credit customer balances. Its risk team sets rules per chain based on the finality model of each network and the size of the deposit.
For a proof of work chain with a low hash rate, the exchange waits for many more confirmations than for Bitcoin, because a deep reorganization would be cheaper to attack. For a BFT chain with deterministic finality, it credits deposits as soon as the block is final, usually within seconds. For Ethereum, it waits until the block is part of a finalized checkpoint.
The result is fast crediting where finality is strong and protection against double-spend attacks where it is weak, without one blanket rule for all networks.