Confirmation Requirement

Overview

The requirement should match the consequence of accepting the payment. A low-value service that can suspend access may tolerate early confirmation, while an irreversible asset delivery may require stronger settlement. The requirement can also change based on whether a transaction uses a native asset, token, bridge, or custodial internal transfer.

A complete rule verifies more than block count. The transaction must succeed, reach the correct destination, use the intended asset, and remain on the canonical chain. Token transfers may require receipt-log verification, while account-based networks can have nonce replacement behavior.

Systems should document who approves requirement changes and retain the version applied to each payment. During network incidents, the required threshold may increase or settlement may pause entirely.

Users benefit from clear communication. A checkout should explain that payment was detected but is still confirming rather than appearing frozen. The requirement defines operational acceptance; it does not change the underlying protocol or guarantee that every future risk is eliminated.

Requirements can also include non-block conditions, such as successful receipt status, matching token contract, and absence of a replacement transaction. Cross-chain deposits may require the source transaction to finalize and the bridge or destination message to complete. The system should expose which component is still pending. This avoids marking a transfer complete merely because one stage reached its local confirmation count.

The requirement should also state whether the transaction must remain final for a minimum observation period before fulfillment. This can be useful in systems where provider data is inconsistent or a secondary settlement layer updates after local confirmation.