Probabilistic Finality

Overview

Understand the idea

Probabilistic finality does not create one instant protocol point after which reversal is mathematically impossible. Instead, confidence grows as more work, stake-supported blocks, or other fork-choice evidence builds on the transaction’s branch.

Reversal probability depends on consensus rules, adversarial resources, network conditions, confirmation depth, and assumptions about honest participation. A chain reorganization can remove transactions from previously accepted blocks or change their order.

Payment systems choose a confirmation threshold that makes residual risk acceptable for a specific amount and fulfillment decision. They should monitor canonical hashes and reorganization events rather than count height alone. Additional confirmations reduce one class of settlement risk, but they do not correct a failed contract execution, wrong recipient, or wrong asset.

What actually happens

Probabilistic finality means confidence in a transaction's permanence increases over time without a protocol event that makes reversal categorically impossible. Bitcoin is a familiar example: as blocks accumulate after a transaction, replacing it ordinarily becomes harder and more expensive, but the probability of a successful history rewrite is not literally zero. The relevant risk depends on attacker resources and incentives, not only a memorized block count.

A network participant compares valid competing histories according to its chain-selection rule. A transaction may appear in the selected chain while another competing history still exists. New work or votes, depending on the design, make one history increasingly costly to displace. Merchants choose their own acceptance thresholds after assessing this model. Independent observers can disagree briefly when blocks propagate unevenly.

Decisions and failure cases

Treat formulas for reversal probability as model-dependent, not as guaranteed loss rates. Network partitions, concentrated mining power and implementation faults can create unusual events. Applications should handle reorganizations even after a transaction has been marked paid, retaining audit evidence and explicit exception procedures.

Related concepts

Finality, Consensus Finality, Instant Finality.

Further reading

Ethereum: Gas and Fees.