Block Finality

Overview

Finality determines when participants can treat blockchain history as settled. Some protocols provide probabilistic finality: the deeper a block is buried under later proof-of-work blocks, the less likely it is to be reorganized. Other protocols provide explicit economic or deterministic finality through validator votes and protocol checkpoints.

Finality is stronger than initial block inclusion. A transaction can appear in a valid block and still be removed during a reorganization. Applications therefore choose acceptance rules based on the network, transaction value, and risk tolerance.

Finality can also have multiple layers. A rollup transaction may be confirmed by its sequencer, included in a layer-2 block, published to a base layer, and later finalized under the base protocol. Each stage provides a different guarantee.

Merchants should avoid treating “seen,” “included,” “confirmed,” and “finalized” as interchangeable. The operational threshold for delivering goods can be lower than absolute finality, but it should be documented and appropriate to the payment risk.

Applications choose settlement thresholds by combining the network’s finality model with transaction value and business risk. A low-value digital service may act after early confirmation, while a high-value or irreversible delivery may wait for explicit finality or a deeper confirmation threshold.

Finality also differs from operational availability. A finalized block can remain difficult to query if an explorer or service is offline, while an easily visible recent block may not yet be final. Cross-chain bridges and rollups can introduce additional waiting periods because users depend on both the originating system and a settlement or dispute mechanism. Payment systems should record whether a transaction is detected, included, confirmed, and finalized instead of collapsing all stages into a single “paid” state.