Reorg Risk

Overview

Reorg risk arises when nodes adopt a different valid chain or ledger branch under the protocol’s fork-choice rules. Transactions in displaced blocks may return to the mempool, appear elsewhere, conflict, or disappear from the accepted history.

Likelihood and impact depend on consensus design, network conditions, validator or miner concentration, block depth, finality rules, and adversarial capability. A displayed confirmation count does not always correspond to irreversible settlement across different networks.

Applications should define network-specific confirmation and finality policies, monitor reorganizations, delay irreversible fulfillment where needed, and reconcile state after changes. Accounting, callbacks, balances, and customer communication must handle a previously observed payment becoming uncertain or invalid.

Metrics for Reorg Risk should distinguish coverage, control execution, alerts, confirmed outcomes, losses, false positives, processing time, exceptions, and unresolved actions.

Reorg Risk is the exposure that an accepted chain history changes and invalidates or reorders transactions under the business’s confirmation and finality assumptions.

Reorg risk is the possibility that a blockchain’s recently accepted history is replaced, changing transaction inclusion, order, or confirmation status. Reorg risk makes recent blockchain state provisional, so fulfillment and accounting must follow network-specific finality and reconciliation rules.

For Reorg Risk, the assessment should evaluate the possibility that a blockchain’s recently accepted history is replaced, changing transaction inclusion, order, or confirmation status. The assessment record should separate observed evidence supporting the possibility that a blockchain’s recently accepted history is replaced, changing transaction inclusion, order, or confirmation status from assumptions, state the time horizon and existing controls, and identify who owns any remaining exposure. Monitoring should test whether the conditions described in the possibility that a blockchain’s recently accepted history is replaced, changing transaction inclusion, order, or confirmation status have changed enough to require a new rating, treatment, or approval.