Chain Rollback

Overview

A chain rollback returns the canonical state to a prior height or checkpoint. It may occur automatically through a reorganization or be coordinated during incident recovery, a failed upgrade, database repair, or governance-directed response to a critical exploit.

Transactions after the rollback point lose their former canonical effects unless they are replayed on the resumed chain. Nonces, balances, contract storage, bridge messages, and external accounting can therefore diverge from records created before the rollback. Operators should identify the exact rollback block hash, not only its height, and rebuild indexes from a safe boundary. Payment services must reverse affected credits, reconcile resubmitted transactions, and suspend cross-chain actions until both sides agree on the surviving history. Finalized states may have stronger guarantees than merely included blocks, but exceptional recovery can still involve governance or software intervention. The likelihood and impact of Chain Rollback depend on consensus design, network partitions, client faults, finality, and participant concentration.

Production monitoring should retain old and new block references, affected transactions, confirmation depths, and the trigger for every business-state change. High-value payment policies should choose thresholds that reflect network-specific reorganization risk. A height alone is insufficient because several valid or invalid branches can contain different transactions at the same position. Chain Rollback should be tied to specific competing block hashes, heights, fork-choice rules, and the point at which the local canonical view changed. Applications affected by Chain Rollback should roll dependent state backward idempotently and then replay the new canonical history. Credits, confirmations, balances, and callbacks must not be duplicated when the same transaction reappears in a different block.