There is a common misconception that being committed to a blockchain's immutability means being against hard forks. It sounds logical, but it is wrong, and the confusion causes a lot of pointless argument. A blockchain can hold immutability as a sacred principle and still hard fork regularly. To see why, you have to separate two very different things that both go by the name "hard fork."
What a hard fork is, mechanically
A hard fork is a change to a blockchain's rules that is not backward-compatible. After the change, nodes running the old software and nodes running the new software no longer agree on what counts as a valid block. Everyone has to upgrade to stay on the same chain. If part of the community refuses, the chain can split into two separate networks that share a common history up to the fork point and diverge after it.
That is the mechanism. But mechanism alone tells you nothing about whether a particular fork is healthy or dangerous. For that, you have to ask what the fork actually changes.
The distinction that matters: rules vs. history
Here is the crucial split.
Forks that change the rules going forward
Most hard forks are protocol upgrades. They fix bugs, adjust economic parameters, add features, or change how the network will behave from that point on. They do not touch what already happened. The ledger's recorded history stays exactly as it was; only the rules for future blocks change.
These forks are not just compatible with immutability — they are often necessary to preserve the chain at all. A network may need to fork simply to defuse a built-in mechanism, patch a vulnerability, or keep the protocol viable. A blockchain that could never upgrade would be a fragile one. Routine, forward-looking forks are a sign of a living, maintained network.
Forks that rewrite what already happened
A very different kind of fork reaches back and alters the recorded ledger — reversing transactions, moving funds that already settled, or erasing events that actually occurred. This is the kind of fork that collides with immutability, because immutability is precisely the guarantee that the past cannot be edited.
The distinction is not academic. The whole reason a network spends enormous resources securing its ledger is to make the record permanent and trustworthy. If the history can be rewritten when the outcome is inconvenient, that guarantee weakens. Every participant now has to wonder whether a future fork might undo a transaction they were relying on.
Why immutability is worth protecting
An immutable public ledger is what lets a blockchain operate without trusted intermediaries. You do not have to trust a bank or a company to keep honest records, because the record cannot be quietly altered. Once you accept that the ledger can be rewritten under enough social pressure, you have reintroduced a version of the very trust dependency the system was built to remove. The precedent is the danger: the first history-rewriting fork makes the second easier to justify.
Fixing the rules for the future keeps a blockchain alive. Rewriting the past to fix a mistake trades away the one property that made it trustworthy.
The genuinely hard cases
None of this means the choice is always obvious. The hardest cases arise when a catastrophic loss — a huge theft or a fatal bug in an application built on the chain — creates enormous pressure to intervene. Rewriting history could return the funds and protect the ecosystem in the short term. Refusing preserves the principle but lets the loss stand.
There is no universally correct answer, and reasonable people have split over exactly this. But the framing should be honest: the debate is not "forks good" versus "forks bad." It is whether the specific fix changes the rules going forward, which almost everyone accepts, or reaches back to rewrite settled history, which is where the real principle is at stake.
The bottom line
Hard forks are not a single thing to be for or against. Upgrading the rules is how a blockchain stays healthy. Rewriting the ledger is a different act entirely, one that touches the foundation of why the system can be trusted without intermediaries. Anyone arguing about forks who has not made that distinction is arguing about the wrong thing.