On-Chain Settlement Finality

RTGS, including Fedwire, TARGET2, and CHAPS: real-time gross settlement arrangements often settle in central-bank money; their legal framework and operating rules specify when a transfer becomes irrevocable.

CLS, FX: payment-versus-payment is designed so that the legs settle together or not at all under the system’s rules.

DNS, including ACH and SEPA: arrangements can have provisional stages followed by later net settlement; the applicable rulebook determines the final point.

EU Settlement Finality Directive: this legal framework protects transfer orders and netting in designated systems, subject to its scope and national implementation.

The common feature is not one settlement asset or one legal mechanism. It is that the relevant agreement, system rulebook and law identify the finality point for that arrangement.

Reversal risk depends on consensus design. On Ethereum PoS, reverting a finalized checkpoint requires violating the protocol’s validator and slashing assumptions. On proof-of-work chains, operators commonly use confirmation windows because the risk model is probabilistic.

The threshold should be expressed as policy rather than a universal number: it depends on value, asset, chain, counterparty, crediting promise and loss-allocation agreement.

An operator must separately state whether the chosen chain guarantee is sufficient for customer crediting or contractual settlement in that arrangement.

Ethereum proof-of-stake has a current chain head and a separate checkpoint-finalization process. The Ethereum Foundation describes a checkpoint as finalized when the required supermajority link is established; reverting that finalized state requires violating the protocol’s validator and slashing assumptions.

The operational point is that a current head and a finalized checkpoint are not the same assurance. A payment operator should say which state it accepts and who bears loss if the earlier state changes.

Bitcoin and Ethereum have structurally different security budgets, but both make large reversals expensive in different ways: Bitcoin through sustained majority hash power, Ethereum through validator corruption and slashing.

Tron is structurally different: 27 super-representatives, elected, control block production. A 20-block threshold is conventional, but the security model depends on the super-representative set rather than on Bitcoin-style industrial hash-rate competition.

Smaller PoW chains illustrate the gap: Ethereum Classic experienced 3,600+ block and later multi-thousand-block reorganizations during 2020 attacks. Security budget is not a label - it is a chain-specific risk model.

Transaction value: higher-value transfers should wait for stronger finality thresholds, because the attacker incentive and operational loss both rise with value.

Counterparty risk profile: regulated FI with bilateral netting agreement can support a lower threshold if reorg loss is recoverable via legal claim. Unknown or non-regulated counterparty requires a stricter threshold and no credit extension during the confirmation window.

Chain security model: Ethereum Casper finality, Tron delegated super-representatives, Bitcoin proof-of-work confirmations, and L2 dispute windows are different models. Each has a different failure mode: Ethereum = validator corruption/slashing; Tron = elected-validator collusion or governance failure; Bitcoin = sustained hash-rate majority; optimistic L2s = L1 finality plus withdrawal/dispute mechanics.

Pragmatic defaults should be calibrated per corridor and reviewed quarterly: deterministic where available, probabilistic with explicit thresholds where not.

Wait for a stated assurance: clearing waits for a documented confirmation or finalized-checkpoint policy before declaring settlement complete. Simple designs avoid advancing value during that interval, but the policy must be chain- and product-specific.

Network-level guarantee: a network may advance value before the chosen chain assurance and accept a defined risk during that window. The guarantee, capital source, exclusions and loss-allocation terms must be explicit; it is not implied by a fast user interface.

Atomic / PvP design: the legs are coordinated so one side is not completed without the other. It can reduce one-sided settlement exposure, but requires a clear technical and legal description of the coordination path.

The architecture choice is a corridor decision. It must name the chain assurance, the payment promise and the party responsible for a failed or reversed transfer.