Forks: Soft, Hard and What They Change

A fork is what happens when two groups of participants disagree about which blocks are valid, or about which chain tip is the real one. The hard fork vs soft fork distinction is the first thing to get right, because the two are not degrees of the same event — they point in opposite directions. A hard fork vs soft fork comparison is really a comparison of who has to upgrade and who is left behind.

Both kinds change rules. Only one kind creates a permanent split when some participants refuse to follow. Getting the direction wrong is how people end up holding an asset on a chain they did not intend to use, or accepting deposits from a chain their software no longer recognises.

• A soft fork tightens the rules. Blocks valid under the new rules are also valid under the old ones, so non-upgraded nodes keep following the same chain.
• A hard fork loosens them. New blocks are invalid to old software, so anyone who does not upgrade is on a different network.
• Splits are optional for hard forks, impossible for soft forks. A soft fork can only split if a majority of hashpower or stake rejects it.
• Upgrade the software before the activation height. Wallets, nodes and signing devices all need to know the new rules in advance.

A fork is a disagreement about validity, not a disagreement about opinion

Nodes are rule engines. They accept a block if every transaction in it satisfies the rules the node enforces, and reject it otherwise. A fork is what happens when two nodes apply different rule sets to the same block and reach different verdicts.

That is why forks are not votes in the ordinary sense. A miner or validator can signal support, but signalling does not change what a node accepts. The rules that matter are the ones running on the machines that validate, and those machines are operated by exchanges, businesses, infrastructure providers and individual users who may never coordinate at all.

Two forks get confused constantly. An accidental fork is a temporary divergence — two miners find a block at nearly the same time, and the network converges on one within a block or two. A rule fork is deliberate and, in the hard case, permanent. The first is normal operation. The second is a governance event.

Hard fork vs soft fork: which direction the rules move

The distinction is about backward compatibility, and it is best tested by asking what an old node does with a new block.

Soft fork: valid under both rule sets

A soft fork restricts what was previously allowed. Old nodes see the new blocks as slightly conservative but still valid, so they accept them and stay on the same chain. Segregated witness and several signature-verification changes were deployed this way. The cost is that old nodes are not fully verifying the new restrictions — they are trusting that the majority enforces them.

Activation usually requires broad signalling. A common historical pattern asked for 95 percent of blocks in a 2,016-block retarget period to signal readiness, which works out to 1,915 blocks. If that threshold is not reached, the fork does not activate, and the proposal either stalls or is retried with different machinery.

Hard fork: invalid under the old rule set

A hard fork relaxes or extends the rules — larger blocks, new opcodes, changed issuance, a different signature scheme. Old nodes treat the new blocks as invalid and stop following them. If a meaningful group keeps running the old software and keeps producing blocks, the result is two chains sharing a history up to the split point and diverging afterwards.

Hard forks are cleaner to reason about and messier to execute. Everyone must upgrade, including custodians and hardware wallets, and anyone who does not is silently on the other network. That is a coordination problem, not a technical one, and coordination failures are the expensive part.

What a hard fork vs soft fork actually changes

A soft fork asks whether everyone will accept less. A hard fork asks whether everyone will accept something different — and “everyone” is the part that fails.

How a fork is actually executed

The sequence is boring when it works and chaotic when it does not, and the difference is almost always preparation.

1. Publish the specification and the activation mechanism — height-based, time-based, or signalling-threshold-based.
2. Release node and wallet software that understands both the old and new rules, so upgrades can happen before the deadline.
3. Confirm that infrastructure providers, custodians and signing devices have upgraded, since they often lag individual users.
4. At the activation point, watch for divergence: block height, chain weight, and peer counts are the early indicators.
5. If a split occurs, verify replay protection, or assume a transaction on one chain can be replayed on the other.
6. Confirm which chain each venue credits, and never assume the ticker resolves the ambiguity — the ticker is a label, not a rule set.

The replay point deserves emphasis. Without protection, a signed transaction is valid on both chains because it satisfies both rule sets. That is not a bug in either chain; it is a consequence of shared history. Sending on one chain can therefore move funds on the other.

Why forks stay risky after they succeed

The dangerous window is not the activation block. It is the weeks after, when balances exist twice on paper and only once in the intended ledger.

Accounting gets ambiguous

Accounting is the first casualty. A holder who had a balance before the split has an equal balance on both chains, but the two assets usually diverge in price, liquidity and support. That divergence is a market outcome, not a protocol one, and it is where most of the confusion lives.

Infrastructure has to disambiguate

Infrastructure is the second. Explorers, indexers and bridge contracts need to distinguish the chains explicitly. A bridge that does not check the chain identifier can be drained by depositing the same transaction on both sides — a defensive design requirement, not an exotic edge case.

Governance precedent is a cost

The third is governance precedent. A fork that succeeds under contested circumstances makes the next contested fork cheaper to attempt, because participants have learned that the outcome depends on coordination rather than on rules alone. That is not necessarily bad, but it is a cost, and it is paid in predictability.