Confirmation

Overview

Before confirmation, a transaction may be known only to mempools, sequencers, or private submission services. It can be delayed, replaced, dropped, or fail to execute. Inclusion in a block gives the transaction an initial position in chain history.

In proof-of-work networks, each later block generally increases the cost of reorganizing the transaction’s block. This creates probabilistic confidence rather than an absolute guarantee. Proof-of-stake networks may combine block inclusion with explicit validator finality, so the number of blocks alone may be less informative.

A payment system should record confirmation count, containing block hash, current canonical height, and finality status. During a reorganization, the count can decrease or return to zero. Token payments also require execution success and correct contract-event verification.

Merchants choose confirmation requirements based on transaction value, goods delivered, network risk, and user experience. Confirmation is therefore a protocol observation used inside a business policy, not a universal signal that every payment can be fulfilled safely.

Some networks expose several confirmation concepts at once, such as safe, justified, and finalized blocks. Applications should use the protocol’s native terminology where possible rather than translating everything into a Bitcoin-style count. Customer messaging can still simplify the process, but internal records should preserve the precise state. This becomes important during incidents, when a transaction may be included and economically safe but not yet formally finalized.

A confirmation can also arrive later than expected without indicating fraud or failure. Fee pressure, missed blocks, or provider delays may simply extend the timeline. Systems should distinguish slow progress from invalid execution and provide clear customer messaging during the wait.