Network Split

Overview

A network split can follow a contentious hard fork, unresolved consensus failure, or prolonged partition where both sides continue independently. Each resulting network may share pre-split history and account keys but develop separate blocks, assets, governance, and market value.

The term is broader and usually more persistent than a temporary fork. Replay attacks are possible when transactions remain valid on both sides unless chain identifiers or replay protection diverge. Wallets and exchanges should assign distinct network identifiers, endpoints, token labels, and confirmation policies. Users need clear warnings that balances may exist separately on each branch. Payment services should pause support until canonical policy, replay protection, liquidity, and operational recovery are understood. Network Split 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 Network Split should roll dependent state backward idempotently and then replay the new canonical history. The likelihood and impact of Network Split 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. Monitoring should retain old and new block references, affected transactions, confirmation depths, and the trigger for every business-state change.