What Is a Blockchain Fork?

In brief

Fork has three related but distinct meanings:

1. Competing-chain fork. Different valid blocks extend the same parent. A network’s fork-choice rule decides which branch becomes canonical; losing Bitcoin blocks are called stale blocks.
2. Consensus-rule fork. Nodes run different validity rules. A hard fork can leave old nodes rejecting the upgraded chain. A soft fork makes some previously valid blocks invalid while keeping upgraded blocks within what old nodes accept.
3. Software fork. A code repository is copied and changed. Nothing happens on-chain unless people run software that creates or joins a network.

“Hard” does not mean contentious, and “soft” does not mean safe or easy. Most Ethereum network upgrades are coordinated hard forks with no lasting rival chain. A chain split is a possible result of incompatible rules, not part of the definition that must persist forever.

Temporary forks and fork choice

In Bitcoin, two miners can produce blocks at the same height at nearly the same time. Nodes may initially accept different tips, but valid nodes follow the chain with the most cumulative proof of work. Once one branch gains more work, blocks abandoned on the other branch are stale. Block height is therefore not a globally unique identifier; a block header hash identifies a particular block.

Other networks resolve competing tips differently. Ethereum proof of stake uses LMD-GHOST to select the branch with the greatest relevant attestation weight, alongside checkpoint finality. On Solana, a validator’s root is its highest block that is an ancestor of all its active forks and has reached maximum vote lockout. These mechanisms are not interchangeable, but each tells a node which history to build on.

Short competing branches are a normal distributed-systems possibility. They are also why applications distinguish a newly included transaction from one with stronger confirmation or finality.

Hard forks: old rules can reject upgraded blocks

A hard-forking rule change allows a block or state transition that old rules reject, or otherwise makes the rule sets incompatible in that direction. If both groups keep producing blocks, histories can remain separate. If nearly everyone upgrades, the old branch may simply stop.

Ethereum calls its scheduled protocol upgrades forks. They change protocol rules and require node operators to install compatible execution and/or consensus clients. The Merge is best treated as a coordinated upgrade spanning Bellatrix on the consensus layer and Paris on the execution layer, not as one ordinary block-number fork.

The 2016 DAO Fork shows the contentious case. EIP-779 records an irregular state change at block 1,920,000 that moved specified balances to a withdrawal contract. Some participants continued the history without that state change, producing the lasting Ethereum/Ethereum Classic split. The fork did not “undo” every prior block; it applied a special state transition at the fork point.

Soft forks: upgraded rules reject more

A soft-forking change narrows the valid-block set. Upgraded nodes reject a class of blocks that old nodes would still accept, while blocks valid under the new rules remain acceptable to old nodes. If enough block production follows and enforces the tighter rules, old nodes can remain on the same most-work chain without understanding the new feature.

Activation is separate from the hard-versus-soft definition. Bitcoin has used height or time activation and miner-readiness signaling. BIP 9, for example, defines version-bit signaling and deployment states for backward-compatible changes; signaling does not make miners the sole authors of the rules, because full nodes decide which rules they enforce.

Segregated Witness is a deliberately engineered soft fork specified in BIP 141. Old nodes can accept witness-program outputs under their older rules, while upgraded nodes enforce the witness commitments and spending rules. “Backward compatible” here concerns block validity. An old wallet still may not understand new addresses, scripts, fee accounting, or security assumptions.

Accidental rule splits are different again

Not every rule split is planned. BIP 50 documents the March 2013 Bitcoin chain fork: Bitcoin 0.8 and some pre-0.8 nodes disagreed because a database-lock limit had effectively become a block-validity rule. Operators coordinated hash power onto the pre-0.8-compatible branch, and the competing branch was abandoned.

This incident was more serious than two miners finding blocks simultaneously. Nodes disagreed about whether a block was valid, so ordinary most-work convergence did not immediately solve it.

User risks around lasting splits

After a lasting split, the two ledgers may begin with the same keys and balances but evolve under different rules. A transaction intended for one chain can sometimes be valid on the other unless the chains or applications provide replay protection. Wallets, exchanges, and explorers may also disagree about which branch a ticker refers to.

Do not treat a hard fork as a token airdrop, a governance poll, or guaranteed “free money.” Users must verify the network, chain identifier, replay behavior, software, and asset identity before transacting.