Fork

Overview

A fork can describe temporary competing blocks under the same rules or a deliberate change to the rules nodes enforce. Temporary forks arise from simultaneous proposals or network delay, while software upgrades can create soft forks, hard forks, or permanent network splits.

The consequences depend on compatibility and adoption. Transactions may be reordered or removed during branch resolution, and assets can appear on both sides of a permanent split while gaining different values and replay risks. Payment systems should identify the fork type, activation point, canonical branch, and replay protection before processing. They must record block hashes, not only heights, and pause during unresolved splits. Wallets should label networks clearly and never assume that matching addresses or balances imply interchangeable assets. Applications affected by Fork 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.

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 Fork depend on consensus design, network partitions, client faults, finality, and participant concentration. 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. Fork should be tied to specific competing block hashes, heights, fork-choice rules, and the point at which the local canonical view changed. When evaluating Fork, a height alone is insufficient because several valid or invalid branches can contain different transactions at the same position.