Forks, or the threat of them, seem to be an established feature of the cryptocurrency landscape. But what are they? Why are they such a big deal? And what is the difference between a hard fork and a soft fork?

A “fork,” in programming terms, is an open-source code modification. Usually, the forked code is similar to the original, but with important modifications, and the two “prongs” comfortably co-exist. Sometimes a fork is used to test a process, but with cryptocurrencies, it is more often used to implement a fundamental change or to create a new asset with similar (but not equal) characteristics as the original.

Not all forks are intentional. With a widely distributed open-source codebase, a fork can happen accidentally when not all nodes are replicating the same information. Usually, these types of accidental forks are identified and resolved. A majority of cryptocurrency forks occur due to disagreements over embedded characteristics, as we'll explore below.

One thing to bear in mind with forks is that they have a “shared history.” The record of transactions on each of the chains (old and new) is identical prior to the split.

There are two main types of programming fork:

A hard fork is a change to a blockchain protocol that renders older versions invalid. If older versions continue running, they will end up with a different protocol and with different data than the newer version. This can lead to significant confusion and possible errors.

With bitcoin, a hard fork would be necessary to change defining parameters such as the block size, the mining difficulty algorithm, limits to additional information that can be added, etc. A change to any of these rules would cause blocks to be accepted by the new protocol but rejected by older versions and could lead to serious problems – possibly even a loss of funds.

For instance, if the block size limit were to be increased from 1MB to 4MB, a 2MB block would be accepted by nodes running the new version, but rejected by nodes running the older version.

Let’s say that this 2MB block is validated by an updated node and added to the blockchain. What if the next block is validated by a node running an older version of the protocol? It will try to add its block to the blockchain, but it will detect that the latest block is not valid. So, it will ignore that block and attach its new validation to the previous one.

Suddenly you have two blockchains, one with both older and newer version blocks, and another with only older version blocks. Which chain grows faster will depend on which nodes get the next blocks validated, and there could end up being additional splits. It is feasible that the two (or more) chains could grow in parallel indefinitely.

This is a hard fork, and it’s potentially messy. It’s also risky, as it’s possible that bitcoins spent in a new block could then be spent again on an old block (since merchants, wallets and users running the previous code would not detect the spending on the new code, which they deem invalid).

The only solution is for one branch to be abandoned in favor of the other, which involves some miners losing out (the transactions themselves would not be lost, they’d just be re-allocated). Or, all nodes would need to switch to the newer version at the same time, which is difficult to achieve in a decentralized, widely spread system.

Or, bitcoin splits, which has happened (hello, bitcoin cash).

A soft fork is essentially the opposite of a hard fork, whereby newly implemented changes remain backward-compatible with older versions.

For example, if a protocol is changed in such a way that tightens the rules, implements a cosmetic change or adds a function that does not affect the blockchain's structure in any way, then new version blocks will be accepted by old version nodes. Not the other way around, though: the newer, “tighter” version would reject old version blocks.

In bitcoin, old-version miners would realize their blocks were getting rejected and would be forced to upgrade. As more miners upgrade to the latest version, the chain with predominantly new blocks becomes the longest, which, in turn, increases the amount of orphan old version blocks that are created and causes more miners to upgrade. This process ensures the system self-corrects. Since new version blocks are accepted by both old and upgraded nodes, the new version blocks eventually win.

For instance, say the community decided to reduce the block size to 0.5MB from its current theoretical limit of 4MB (with SegWit blocks.) New version nodes would reject blocks with the old limit and would build on the previous block (if it was mined with an updated version of the code), which would cause a temporary fork.

This is a soft fork, and it’s already happened several times. Initially, Bitcoin didn’t have a block size limit. Introducing the limit of 1MB was done through a soft fork since the new rule was “stricter” than the old one.

The pay-to-script-hash function, which enhances the code without changing the structure, was also successfully added through a soft fork. This type of amendment generally requires only the majority of miners to upgrade, which makes it more feasible and less disruptive.

Soft forks do not carry the double-spend risk that plagues hard forks, since merchants and users running old nodes will read both new and old version blocks.

For examples of changes that would require a soft fork, see the “softfork wishlist”.