Forked Chain

Overview

A forked chain begins from a common ancestor and then diverges. It may be a short-lived branch later orphaned by normal consensus or a persistent network created by incompatible software rules and community adoption.

Persistent forks can duplicate balances, contracts, and transaction history at the split point. Assets afterward are distinct even when addresses, symbols, or code initially match. Transactions without replay protection may be valid on both chains. Wallets and exchanges should verify genesis, fork point, chain ID, replay rules, native asset, and supported endpoints before enabling activity. Payment systems must never combine confirmations or balances across forks. Bridges and oracles need separate deployments and security evaluation for each continuing chain. 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.

Forked Chain 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 Forked Chain should roll dependent state backward idempotently and then replay the new canonical history. The likelihood and impact of Forked Chain 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.