Confirmed Block

Overview

In proof-of-work usage, a block becomes confirmed when it is in the best chain, and each block added above it increases confirmation depth. In BFT systems, a block may be described as confirmed after a quorum commits it. Proof-of-stake APIs can also use confirmed, safe, justified, or finalized as distinct commitment levels. These labels are not portable across networks and sometimes differ between providers on the same network.

A block can be confirmed without every transaction producing the intended result. Transaction receipts or state changes must still be checked. It can also lose canonical status through a reorganization if the confirmation level was provisional. A Block Confirmation policy should specify exact evidence, such as depth, signed commit, or finalized checkpoint, rather than accepting an explorer’s generic label.

Payment risk determines how much confirmation is enough. Low-value, reversible services may act on an early confirmed block, while asset release, treasury movement, or cross-chain minting requires stronger assurance. Network incidents can change normal assumptions by increasing reorganization risk or causing Delayed Finality. Systems should support policy overrides and avoid hardcoding one number for all chains, assets, and transaction values.

Operational records should include block ID, block number, parent ID, confirmation count, canonical status, finalized status, and observation source. These fields allow software to detect replacement at the same number and to reverse provisional accounting. A block should move through states rather than jump directly from pending to permanently confirmed. This state model gives payment teams a clear basis for releasing goods, credit, or downstream transactions.