Forks and reorganizations, and what each one costs
A fork may be a one-block race, a coordinated rule change, or an attack; the three differ in cost by orders of magnitude.
Three quite different events share the word fork. One is a routine accident that happens whenever two valid blocks appear at nearly the same moment. One is a deliberate change to the rules, coordinated in advance. One is an attack that rewrites recent history at great expense. Their costs differ by many orders of magnitude, and conflating them is the source of most confusion about how stable a ledger really is.
The accidental fork
Blocks travel through a peer-to-peer network at finite speed. If two miners or validators produce a valid block at the same height before either has heard of the other, part of the network sees one first and part sees the other. Both groups are following the rules correctly. The disagreement resolves at the next block: whichever branch is extended first becomes heavier, and nodes on the other branch switch, discarding the block they had accepted.
The discarded block is called an orphan, or an uncle on chains that reward it partially. Its producer loses the reward and the fees, which is a direct financial cost of propagation delay. The frequency of these events is governed by the ratio of propagation time to block time, which is why chains targeting very fast blocks must work harder on networking and why fast blocks are not free. This kind of chain reorganization is one block deep, happens routinely on some networks, and is invisible to anyone waiting a few confirmations.
Deliberate reorganizations, and what they cost
A deep reorganization is an attack, and its budget can be reasoned about even when its likelihood cannot. On a proof-of-work chain the attacker needs enough hash power to outpace the honest network for the duration of the reorganized span, which means renting or owning that capacity, plus the rewards forgone by not mining honestly, plus the risk that the assets acquired are frozen by counterparties who notice. Smaller chains that share a hashing algorithm with a much larger one are structurally more exposed, because capacity can be redirected from elsewhere rather than built.
On a proof-of-stake chain with finalized checkpoints, reverting a finalized block requires holders of at least a third of the staked supply to sign contradictory messages, which are permanently visible and trigger slashing. The cost is therefore not rented capacity but destroyed capital. In both cases the same limit applies as in any 51 percent attack: reorganization changes the order and inclusion of transactions, and nothing else. It does not let an attacker sign for coins they do not control, and it does not let them push through blocks that break the rules, because every full node validates independently.
Rule changes: soft and hard
A soft fork narrows the rule set. Blocks that were valid under the old rules may become invalid under the new ones, but every block valid under the new rules is still valid under the old ones, so nodes that have not upgraded continue to accept the chain. This backward compatibility is what makes soft forks deployable without simultaneous action by everyone, and it is also why they are sometimes criticized as changes that non-upgraded users accept without deciding.
A hard fork does the opposite: it permits something the old rules forbade, so old nodes reject the new blocks. Every participant must upgrade, and the change must activate at an agreed block height or epoch. Ethereum has used coordinated hard forks repeatedly, including EIP-1559 in 2021 and the 2022 transition from proof of work to proof of stake, both of which activated without a lasting split of the main network.
When a fork becomes two ledgers
A hard fork splits the network permanently only if a meaningful group keeps running the old rules. When that happens, the ledger's history is shared up to the split point and divergent after it, so every balance that existed before appears on both chains. That is not new value created; it is one claim becoming two claims on two separate systems, each with its own consensus mechanism participants, its own security budget, and its own future.
The practical hazards are specific. Transactions can sometimes be replayed on the other chain unless replay protection is added. Exchanges and custodians decide independently which chain keeps the original ticker, and that decision is commercial rather than technical. The minority chain typically retains a small fraction of the original hash power or stake, which changes its reorganization economics immediately and substantially. Data providers must decide how to treat supply and history across the split, which is a methodology question with no universally agreed answer.
Reading the risk
No single figure captures reorganization risk, but several bound it. Hash rate or staked supply indicates what an attacker would have to match. The Nakamoto coefficient indicates how few parties would need to cooperate rather than compete. Node count indicates how many independent checkers would reject an invalid block outright. And block time converts any confirmation policy into wall-clock time. A chain can score well on one of these and poorly on another, which is the reason to read them together rather than looking for a single safety number.
One further mechanism deserves naming here because it lives at the same layer. Block producers can also reorder or insert transactions within the blocks they build, which is MEV, and in extreme designs the pursuit of it creates an incentive to reorganize a block or two in order to capture value that was already recorded. Specialized block builders now assemble blocks for proposers on some networks, which changes who holds that power without removing it.
The next lesson looks at those producers directly: who they are and how they are paid. For historical cases of splits and failed reorganization defenses, see incidents, and for how forks are handled in supply figures, see methodology.