Transaction Finality

Overview

Proof-of-work networks generally provide probabilistic finality. Each additional block makes reorganizing a transaction more costly, but no fixed depth creates mathematical impossibility. Applications choose an acceptable threshold based on value and network security.

Proof-of-stake systems can provide explicit finality through validator votes or checkpoints. Reversing finalized history may require violating slashing conditions, social coordination, or a protocol-breaking event. Some systems expose several states such as processed, safe, justified, and finalized.

Layer-two and cross-chain transactions can have multiple finality stages. A rollup transaction may be accepted by a sequencer, posted to the base chain, proven, and then become withdrawable. A bridge may wait for source-chain finality before recognizing the transfer elsewhere.

Applications should store block hash, finality state, and policy version. Provider labels can differ, so the underlying protocol status matters. Reorganizations or finality delays should move transactions back to review when appropriate.

Transaction finality is the technical basis for settlement, but business approval can remain separate. A final payment may still need compliance review, order validation, or customer support before fulfillment.

Finality monitoring should rely on protocol-native indicators where available rather than translating every network into an arbitrary block count. Systems supporting several chains can normalize user-facing labels while retaining exact technical status internally. During abnormal conditions, automated fulfillment may pause even if the ordinary threshold is reached. This incident override should be documented and reversible, with clear criteria for returning to normal settlement rules. Finality criteria should also be reviewed after upgrades or incidents that alter consensus participation or settlement behavior.