A blockchain fork sounds like a technical accident, but it is a governance event. It happens when the participants running the software stop agreeing on which blocks count as valid.

Rules live in software, not in a rulebook

A blockchain has no central authority deciding what is legitimate. The rules exist as code running on thousands of independent machines, each checking every block against the same conditions.

When someone proposes a change, they publish new software. Nothing forces anyone to install it, and the network only changes if enough operators choose to run the new version.

That makes every upgrade a vote taken with machines rather than ballots. Adoption is voluntary, gradual, and visible to anyone who cares to count the nodes.

Soft forks tighten the rules

A soft fork narrows what is acceptable. Blocks that satisfy the new, stricter rules also satisfy the old ones, so machines running old software still accept the chain.

This backward compatibility is why soft forks are the less disruptive path. Operators who never upgrade continue following the same chain as everyone else, unaware anything changed.

The tradeoff is scope. Because the new rules must remain a subset of the old ones, a soft fork cannot add capabilities that older software would reject outright.

Hard forks widen them

A hard fork loosens or replaces the rules, so blocks valid under the new software look invalid to the old. The two versions can no longer agree on a single history.

If everyone upgrades before the change activates, nothing visible happens and the network simply moves on. Coordination, not code, is what keeps a hard fork uneventful.

If a meaningful group refuses, the chain splits. Two networks continue from the same shared history, each with its own ledger and its own set of participants.

A split duplicates balances without creating value

At the moment of a split, every balance exists on both chains because both inherited the same prior transactions. Holders find the same amount recorded twice.

That duplication is bookkeeping, not wealth. What each side is worth afterwards depends on which developers, miners or validators, exchanges and users stay with it.

Historically most splits leave one dominant chain and one much smaller one, though the outcome is decided by participants over months rather than at the moment of the fork.

Why forks are difficult to reverse

Once two chains have accumulated separate blocks, merging them would require discarding one history. Transactions confirmed on the abandoned side would vanish.

Exchanges and wallet software then face a practical problem: they must decide which chain carries the original ticker and how to handle the other.

Those naming decisions are made by companies, not by the protocol, which is why the aftermath of a fork often looks more like a commercial dispute than an engineering one.