Fork Resolution

Overview

Fork resolution occurs when the protocol’s fork choice and finality rules give one temporary branch enough support to become canonical. Nodes roll back orphaned blocks, apply the winning branch, and update transactions, balances, and events accordingly. For a permanent rules dispute, technical consensus may not reunify the network. Communities, exchanges, and applications instead choose which forked chain to support, and both histories can continue with separate assets and governance.

Payment systems should wait for appropriate finality, reverse orphaned credits, and rescan replacement blocks idempotently. During permanent splits they need explicit chain identifiers, replay protection, asset naming, and listing policy. Resolution is incomplete until dependent bridges, oracles, and external accounting reconcile the chosen history.

Fork Resolution 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. Credits, confirmations, balances, and callbacks must not be duplicated when the same transaction reappears in a different block. Applications affected by Fork Resolution should roll dependent state backward idempotently and then replay the new canonical history.

The likelihood and impact of Fork Resolution 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. Operational monitoring should retain old and new block references, affected transactions, confirmation depths, and the trigger for every business-state change.