Chain Reorganization

Overview

A chain reorganization, or reorg, happens when a node changes its canonical branch. Blocks from the former branch become stale or orphaned, while blocks from a competing branch take their place. Transactions may reappear, disappear, or execute in a different order. Short reorganizations can be normal in probabilistic consensus, whereas deep or finalized reorganizations may indicate severe faults, attacks, or exceptional recovery. Effects include changed balances, contract state, transaction nonces, and event logs.

Payment systems must associate every observed transfer with its block hash and confirmation status. On a reorg, they should remove orphaned effects, rescan the replacement branch, and prevent duplicate crediting. Required depth should reflect the network’s consensus, value at risk, and current operating conditions. Credits, confirmations, balances, and callbacks must not be duplicated when the same transaction reappears in a different block. Applications affected by Chain Reorganization should roll dependent state backward idempotently and then replay the new canonical history.

The likelihood and impact of Chain Reorganization depend on consensus design, network partitions, client faults, finality, and participant concentration. Finalized states may have stronger guarantees than merely included blocks, but exceptional recovery can still involve governance or software intervention. High-value payment policies should choose thresholds that reflect network-specific reorganization risk. Production monitoring should retain old and new block references, affected transactions, confirmation depths, and the trigger for every business-state change. Chain Reorganization should be tied to specific competing block hashes, heights, fork-choice rules, and the point at which the local canonical view changed. A height alone is insufficient because several valid or invalid branches can contain different transactions at the same position.