Payment Finality

Overview

Payment Finality applies blockchain settlement evidence to a particular payment. A transaction can reach protocol finality, but the payment is not valid if it used the wrong asset, destination, amount, or reference.

On proof-of-work networks, finality is normally probabilistic and managed through confirmation depth. On BFT or proof-of-stake networks, software can use deterministic finalized checkpoints or certificates.

The payment system’s Finality Policy determines when the residual reversal risk is acceptable for credit or fulfillment. Different actions can require different thresholds even for the same transaction.

Finality differs from a Confirmed Transaction. A transaction can be confirmed by one block or provider status while still below the merchant’s finality threshold.

Records should preserve finality evidence, detection time, policy version, and downstream actions. If a rare protocol incident challenges an earlier assumption, the system needs an exception and reconciliation process.

Different operational actions can have different finality points. A merchant may show payment received after early confirmation, release a digital item after a stronger threshold, and permit withdrawal only after protocol finality. Modeling these stages separately avoids forcing one finality label to control every customer, treasury, and accounting decision.

Finality reporting should specify the chain layer involved. A bridged or layer-two payment may be final within one system while withdrawal to another layer still depends on additional proofs, challenge periods, or bridge settlement.

Treasury systems should distinguish final customer receipt from final availability of converted or withdrawn settlement funds across any additional networks or providers.

The finality record should also identify whether the payment depended on a bridge, custodian, or layer-two settlement path.