Block Confirmation

Overview

When a valid block first becomes part of the Canonical Chain, applications commonly describe it as having one confirmation. Each later block that descends from it increases its depth. This convention is common in proof-of-work payment processing because replacing the block would require rebuilding the work for it and its descendants. The exact counting convention can differ between APIs, so integrations should confirm whether the containing block counts as the first confirmation.

Confirmation is not the same as execution success. A transaction can be included in a confirmed block but fail according to its receipt. Nor is confirmation always equivalent to finality. A proof-of-stake network may expose an explicit finalized checkpoint, while recent blocks remain only justified or head-selected. A Confirmed Block can still be reorganized if it has not reached the network’s stronger finality condition.

Required confirmation depth should reflect risk rather than one universal number. Transaction value, attack economics, observed chain stability, double-spend exposure, and whether goods can be recovered all matter. Cross-chain systems may require stricter source confirmation because a later reversal can create unbacked assets or inconsistent messages. During an incident, software bugs, or validator disruption, normal confirmation assumptions may need temporary adjustment.

Payment systems should store the transaction ID, block ID, block number, confirmation count, canonical status, and finalized status separately. They should update these values continuously and detect reorganizations instead of setting an irreversible confirmed flag. Multiple providers can reduce dependence on one stale node, but they do not replace protocol verification. Settlement policy should clearly state which evidence releases low-value, high-value, and irreversible business actions.