Opinion: Hard Forks are necessary for eliminating technical debt, reducing excessive complexity, and keeping blockchains secure from outdated and insecure protocols

TL;DR: It's ok to hard fork. They reduce technical debt, complexity, and security risks. Even Bitcoin has hard-forked before.

What is a Hard Fork?

Hard forks are common for blockchains. Most newer and modern blockchains use a mix of soft and hard forks for updates. Older blockchains often soft fork to maintain backwards compatibility with old and insecure client versions.

By definition, a hard fork is an update or event that will result in a chain split if block producers and node clients continue using different versions.

Soft Forks result in code bloat, dangerous practices, and technical debt:

Soft forks maintain backwards compatibility with older clients, so they need to add additional code logic to detect and deal with all the different types of clients they might encounter. This creates developer complexity and code bloat by continuously supporting archaic and dangerous practices.

Imagine what would happen without hard-forks:

• Newer WiFi routers would still support the insecure WEP or WPA protocol
• Browser would still support old, insecure versions of SSL
• Newer computers would still support Windows 3.0 (launched 1990) natively
• Windows 11 would still support early 1990s Intel 386-generation hardware.
• All city roads would still allow for horses and wagons.
• All US stores would still accept 3-cent, 5-cent and 10-cent paper notes; and half-cent, 2-cent, and 3-cent, and large cents; and $100,000 bills.
• Doctors would still support dangerous practices such as bloodletting, mercury prescriptions, arsenic prescriptions, and trepanning (drilling holes into skulls)

It's dangerous to never hard fork.

Bitcoin soft forks results in complexity and update delays

Bitcoin still supports many outdated legacy addresses such as P2PK, P2MS, P2PKH, P2SH, P2WPKSH, P2WSH. Each of these has their own special quirks, and every Bitcoin client needs to add additional complexity to support them. Many of these aren't quantum secure and should be prevented from transferring in the future, which requires a hard fork.

Bitcoin nodes also take forever to update to a new version. It wasn't until mid-2024 that most clients supported transferring to Bech32m addresses that were introduced in May 2021. Taproot, which requires Bech32m support, also took nearly half a decade to obtain significant client support. That's because unlike with hard forks, Bitcoin nodes aren't required to support the latest features. So it takes the Bitcoin network half a decade to pick up new features.

Bitcoin has hard-forked at least twice, and that's perfectly fine

Lastly, contrary to popular opinion, Bitcoin's canonical chain has actually hard forked at least twice unintentionally.

1. There was a temporary 0.8 update related to the 2013 reorg (where a 51% attack and double-spend also occurred). Had the update been planned as a hard fork instead of soft fork, there wouldn't have been a disastrous chain split.
2. The 0.3.6 OP_NOP update also resulted in a hard fork a year later when the first OP_NOPX transaction was submitted in block 163685.

Pre-0.3.6 Bitcoin clients no longer sync with newer versions due to a hard fork, and that's not a bad thing. No one should be running archaic versions of Bitcoin client.

Jameson Lopp discovered that 7 out of 21 known Bitcoin consensus updates were of the hard fork type and not the soft fork type. They could've been triggered by a "poisoned" transaction like in the November 2025 Cardano chain split, but no one ever submitted one for 5 of them. These include Bitcoin 0.2's best chain selection logic, Bitcoin OP_VER update prior to 0.3.6, the scriptSig bug patched in v0.3.7, the critical inflation bug patched in v0.15.