Forks: When a Network Splits

Concepts: What Is a Fork, Soft Fork, Hard Fork, ETH/ETC & BTC/BCH, Ethereum Forks, Coins at Fork

:::section{mins=1} What Is a Fork :::

:::lead A [[gloss:fork|fork]] is a change to [[gloss:blockchain|blockchain]] rules. Sometimes everyone agrees. Sometimes the network splits in two. :::

:::p A [[gloss:blockchain|blockchain]] runs on rules embedded in every [[gloss:node|node]]'s software: what counts as a valid block, what's the max size, what's the [[gloss:mining|mining]] reward. These rules are the protocol. When rules need changing — that's a [[gloss:fork|fork]] (from the English “fork” — a branching point). :::

:::p If everyone accepts the change, it's just an upgrade — the network continues as one. If part of the network refuses — it splits into two independent chains, each running by its own rules. :::

:::p [[gloss:fork|Forks]] happen all the time. The London upgrade on [[gloss:ethereum|Ethereum]] in 2021 changed fee economics, but the network stayed unified. The Bitcoin Cash split in 2017 created a separate network with its own coin. Both are [[gloss:fork|forks]] — with completely different outcomes. That's why distinguishing their types matters. :::

:::callout{icon=💡} Imagine a board game played by thousands of people worldwide. If someone proposes a rule change but some players refuse — two versions of the game emerge. Both work, but they're no longer compatible with each other. :::

:::keypoints{label="Key Points"}

  • [[gloss:fork|Fork]] = a change to the protocol rules
  • Planned [[gloss:fork|fork]]: everyone updates, one network continues
  • Contentious [[gloss:fork|fork]]: disagreement → two networks, two tokens
  • Natural [[gloss:fork|fork]] (two blocks at same height) is normal and resolved automatically :::

:::details{badge=Advanced title="Fork-Choice Rule, Natural Forks & Reorgs"} :::p When two miners find a valid [[gloss:block|block]] simultaneously, two competing chains briefly exist — this is a natural [[gloss:fork|fork]]. It resolves itself: the next block added to one branch makes it longer, all [[gloss:node|nodes]] switch to it, and the shorter branch is forgotten. :::

:::p The fork-choice rule determines which branch is “correct.” [[gloss:bitcoin|Bitcoin]]: longest chain (greatest cumulative [[gloss:proof of work|proof of work]]). [[gloss:ethereum|Ethereum]] [[gloss:proof of stake|PoS]] uses LMD-GHOST: the branch supported by the most [[gloss:validator|validator]] votes wins. :::

:::p [[gloss:transaction|Transactions]] from the discarded branch aren't lost — they return to the [[gloss:mempool|mempool]] and get included in a future [[gloss:block|block]]. This is why a transaction with zero confirmations isn't considered final. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-1-5-s1 correct=1 explanation="Correct. A [[gloss:fork|fork]] is simply a rule change. If everyone updates — the chain continues as one. If some [[gloss:node|nodes]] refuse — they keep following the old rules, creating two separate but historically identical chains."} What is a [[gloss:blockchain|blockchain]] [[gloss:fork|fork]]?

  • A hack that splits user funds across two wallets
  • A change to the protocol rules — sometimes creating two separate chains
  • A copy of the blockchain made for testing purposes
  • A scheduled maintenance event when the blockchain pauses :::

:::section{mins=2} Soft Fork :::

:::lead A [[gloss:soft fork|soft fork]] tightens the rules. Old [[gloss:node|nodes]] keep working — they just don't use the new features. :::

:::p A [[gloss:soft fork|soft fork]] is a backward-compatible protocol update. [[gloss:node|Nodes]] running old software continue working in the same network — they just don't use the new features. New rules are always stricter than old ones: a [[gloss:block|block]] valid under new rules is also valid under old rules. :::

:::p Example: reducing the maximum block size from 4 MB to 2 MB. For an old node, a 2 MB block is valid — it doesn't exceed the limit. No split, the network stays unified. :::

:::p This is exactly how SegWit was activated in [[gloss:bitcoin|Bitcoin]] in 2017 — an important upgrade that fixed a vulnerability in [[gloss:transaction|transaction]] signatures. Its architectural change later made possible the Lightning Network — a separate fast-payment system built on top of Bitcoin. :::

:::callout{icon=💡} A new traffic rule lowers the speed limit from 60 to 40 km/h. Cars driving at 40 don't violate either old or new rules. No split happens — everyone uses the same road. :::

:::keypoints{label="Key Points"}

  • Backward-compatible: new blocks are valid under old rules too
  • Does not split the network — the preferred update method when possible
  • [[gloss:bitcoin|Bitcoin]] examples: SegWit (2017), Taproot (2021)
  • Limitation: can only tighten rules, never loosen them :::

:::details{badge=Advanced title="SegWit, Taproot & Activation Mechanisms"} :::p SegWit (Segregated Witness, 2017): moved signatures outside the transaction body into a separate “witness” structure. This fixed transaction malleability — the vulnerability exploited in the Mt.Gox incident — and effectively quadrupled throughput. :::

:::p Taproot (2021) added Schnorr signatures. The key effect: complex transactions (multisig, scripts) look identical to simple ones on-chain — better privacy and lower fees for complex use cases. :::

:::p Soft fork activation mechanics matter. SegWit was blocked by large miners under BIP-9 (95% miner signaling required). The community responded with UASF (User-Activated Soft Fork). Full node operators — those who independently verify all transactions and blocks — announced that from a specific date their nodes would reject blocks without SegWit support. A miner can produce a block, but if nodes don't accept it, the block loses its value. This economic pressure worked: miners activated SegWit. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-1-5-s2 correct=2 explanation="Correct. [[gloss:soft fork|Soft forks]] are backward-compatible. New rules are a subset of old rules — old [[gloss:node|nodes]] see new blocks as valid. No chain split occurs. SegWit activated in 2017 without splitting [[gloss:bitcoin|Bitcoin]]."} SegWit was a soft fork on Bitcoin. What does that tell you about it?

  • It created a new separate coin alongside Bitcoin
  • Old Bitcoin nodes that didn't upgrade stopped working
  • Old nodes could still participate — they just didn't use the new features
  • It required every user to upgrade within 30 days or lose their funds :::

:::section{mins=2} Hard Fork :::

:::lead A [[gloss:hard fork|hard fork]] is incompatible with old software. Old [[gloss:node|nodes]] reject new [[gloss:block|blocks]]. Disagreement → two separate networks. :::

:::p A [[gloss:hard fork|hard fork]] changes the rules so that old and new [[gloss:node|nodes]] can no longer operate in the same network. A [[gloss:block|block]] valid under new rules is rejected by old nodes — and vice versa. This is the fundamental difference from a [[gloss:soft fork|soft fork]], which preserves backward compatibility. :::

:::p If the entire community agrees in advance, a [[gloss:hard fork|hard fork]] goes smoothly. All [[gloss:node|nodes]] update before a specific [[gloss:block|block]], old versions gradually leave the network. This is how [[gloss:ethereum|Ethereum]] upgrades work: London, The Merge, Dencun — all hard forks, most users never notice them. :::

:::p If part of the community strongly disagrees, a split occurs. Those opposed continue under the old rules. Two separate networks emerge, sharing history up to the split point but with fully independent futures — their own coins, their own price, their own community. :::

:::howto{label="How to think about this"}

  • A fork is not a bug. It's how power and values are negotiated in a system with no CEO and no government.
  • When a community can't agree — it splits. The market then votes with money which version of the truth it believes in.
  • ETH/ETC was not a technical question. It was: is immutability absolute, or can humans override code in extreme cases? :::

:::callout{icon=💡} A country adopts a new constitution. If everyone agrees — the old one is replaced and one country continues. If part of the population refuses to recognize it — two states form with different laws but identical history. :::

:::keypoints{label="Key Points"}

  • Not backward-compatible: old nodes reject blocks from upgraded nodes
  • Contentious fork: two networks with identical history, but different future
  • All balances duplicate: 10 ETH before [[gloss:fork|fork]] → 10 ETH + 10 ETC after
  • [[gloss:replay attack|Replay attack]] risk: without chain ID, one signature works on both chains :::

:::details{badge=Advanced title="Replay Protection & EIP-155 (chainId)"} :::p After the ETH/ETC fork in 2016, both networks initially had no replay protection. A transaction sent on Ethereum was technically valid on Ethereum Classic too. An attacker could copy your signed transaction to the other chain and drain your coins there. :::

:::p EIP-155 fixed this by including chainId — a unique network identifier — in the transaction signature itself. Ethereum mainnet uses chainId = 1, Ethereum Classic = 61, Arbitrum = 42161. A transaction signed for one network is invalid on another because the signatures contain different chainIds. :::

:::p Today chainId is built into every EVM-compatible network. When adding a new network in MetaMask, you always see its chainId — that's the replay protection at work. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-1-5-s3 correct=0 explanation="Correct. The DAO hack stole ~$60M. The community faced a values question: is code truly immutable (ETC position) or can humans override it in extreme cases (ETH position)? The [[gloss:hard fork|hard fork]] reversed the hack — creating two chains: ETH and ETC."} In 2016 Ethereum hard-forked after the DAO hack. What fundamental question did the community face?

  • Should the stolen funds be returned to victims — overriding the 'code is law' principle?
  • Should Ethereum increase its block size like Bitcoin Cash later did?
  • Should the Ethereum Foundation be dissolved and governance decentralized?
  • Should mining be replaced with staking to save energy? :::

:::section{mins=2} Famous Forks :::

:::lead [[gloss:bitcoin|Bitcoin]] split into BTC and BCH. [[gloss:ethereum|Ethereum]] split into ETH and ETC. Each split is a story of ideological conflict. :::

:::p In 2016, The DAO [[gloss:smart contract|smart contract]] raised around $150 million from thousands of investors — the first large-scale experiment in decentralized capital governance. A hacker found a vulnerability and used it to drain around $60 million. Technically, it was legal by the contract's own rules: the code did exactly what it was written to do. :::

:::p The community faced a choice with no right answer. Some argued that blockchain must be immutable — “code is law” — and no majority had the right to reverse someone else's loss. Others countered that a system built by people for people shouldn't allow theft to stand, that doing nothing would betray the trust of thousands. The majority voted for a fork and reversed the hack — that became the Ethereum we know today. The minority refused to accept this decision and continued on the original chain — that's Ethereum Classic. :::

:::p In 2017, Bitcoin split over a different question: how to scale. One camp wanted to increase block size directly — more transactions per block, higher throughput. The other proposed keeping blocks small and building additional layers on top — SegWit and the Lightning Network. After years of failed compromise, the large-block camp launched Bitcoin Cash with 8 MB blocks. Later, Bitcoin Cash itself split, producing Bitcoin SV — and the argument continued inside the new community. :::

:::callout{icon=💡} Can social consensus override cryptographic consensus? Ethereum: yes, in extreme cases. Bitcoin philosophy: no, never. Neither is objectively right — it's a values question. :::

:::keypoints{label="Key Points"}

  • ETH/ETC: immutability vs. correcting a real theft — no objectively right answer
  • BTC/BCH: on-chain scaling vs. layer 2 — the scaling debate continues today
  • Market cap reflects community support: ETH dominates ETC ~130:1
  • Contentious forks can recurse: BCH → BSV shows splits don't stop after one round :::

:::details{badge=Advanced title="The DAO Hack: Reentrancy & Irregular State Change"} :::p The DAO attack exploited a reentrancy vulnerability. The withdraw() function sent ETH before updating the balance. The hacker's contract called withdraw() recursively upon receiving ETH — before the balance could be zeroed — draining funds in a single transaction. :::

:::p Ethereum responded with an "irregular state change" — the only time in blockchain history when state was modified not through a transaction but directly in client code. Developers hardcoded an exception: "at block X, move these funds back." This became the split point: those who refused to accept intervention stayed on the original chain — Ethereum Classic. :::

:::p Reentrancy remains one of the most common smart contract vulnerabilities. The DAO attack established the checks-effects-interactions pattern as standard practice: check conditions first, update state second, make external calls last. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-1-5-s4 correct=2 explanation="Correct. The DAO hack forced a choice with no objectively right answer. “Code is law” said the hack result was legitimate by contract rules. The opposite view said a system built for humans shouldn't let theft stand. The split happened because neither side could convince the other — both kept their beliefs, and two chains emerged."} Why did the ETH/ETC split happen? Which of the following best describes the core disagreement?

  • A technical bug forced developers to split the chain into two
  • The community couldn't agree on the mining reward amount
  • A philosophical question with no objective answer: must blockchain be immutable, or can humans override code in extreme cases?
  • Miners wanted larger blocks, developers wanted smaller ones :::

:::section{mins=2} Ethereum Upgrades :::

:::lead [[gloss:ethereum|Ethereum]] upgrades via planned [[gloss:hard fork|hard forks]]. Everyone updates — no split. Each [[gloss:fork|fork]] has a name, a [[gloss:block|block]] number, and a set of EIPs. :::

:::p Every Ethereum upgrade is coordinated in advance. Clients are different implementations of the Ethereum protocol (Geth, Nethermind, Besu, Erigon), written by separate teams in different programming languages. They all agree on a specific block number when new rules take effect. After that block, old versions simply stop being compatible with the network. :::

:::p When everyone agrees in advance, a hard fork is just a version change — like updating an app. No split, the network continues under new rules. Most users hear about the upgrade only through news; their assets and transactions work as before. :::

:::p The clearest example is The Merge in 2022. [[gloss:ethereum|Ethereum]] switched from [[gloss:proof of work|Proof of Work]] to [[gloss:proof of stake|Proof of Stake]] in a single [[gloss:block|block]], without halting the network or losing user funds. This required years of coordination between dozens of teams — execution client developers, [[gloss:consensus|consensus]] client developers, staking providers, exchanges. A small group of dissenters tried to continue under the old rules, creating the ETHW chain — but it captured almost no economic activity. That's the strength of a planned [[gloss:fork|fork]]: when the overwhelming majority acts in concert, the alternative chain becomes marginal. :::

:::callout{icon=💡} Ethereum's planned forks are like OS updates on your phone. Everyone updates, the old version disappears, and the phone keeps working. Nobody calls it a "split" — because everyone agreed in advance. :::

:::keypoints{label="Key Points"}

  • Planned hard forks are Ethereum's standard upgrade mechanism
  • Upgrades are named after cities: Homestead, Byzantium, London, Dencun…
  • The Merge (2022): the largest hard fork — switched consensus from PoW to PoS overnight
  • Roadmap: The Surge (scaling) → The Scourge (MEV) → The Verge (Verkle) → The Purge (history) :::

:::details{badge=Advanced title="EIP Process, AllCoreDevs & Ethereum Roadmap"} :::p EIP (Ethereum Improvement Proposal) is the formal process for proposing changes to Ethereum. Anyone can write one, but the path to implementation is long: Draft → Review → Last Call → Final. Core EIPs require rough consensus at AllCoreDevs — weekly calls with all client teams. There's no formal vote; decisions emerge from developer discussion. :::

:::p The Ethereum roadmap has several parallel tracks. The Merge (completed 2022): PoW to PoS. The Surge: scaling via rollups and danksharding, targeting 100,000+ TPS. The Scourge: reducing MEV and staking centralization. The Verge: Verkle trees for lighter state verification. The Purge: removing historical data to reduce node burden. The Splurge: miscellaneous improvements. :::

:::p The roadmap isn't fixed. Priorities shift, timelines move, stages overlap. Ethereum has no single “CEO” making decisions — it's coordination across thousands of contributors. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-1-5-s5 correct=1 explanation="Correct. Technically a hard fork is about rule incompatibility — old nodes can't validate new blocks. A split happens only if some meaningful part of the community keeps running the old rules. Ethereum coordinated The Merge with all client teams months in advance, and although a tiny PoW fork (ETHW) did appear, it captured almost no economic activity — so in practice the network stayed unified."} Ethereum's The Merge (2022) was technically a hard fork. Yet it didn't split the network into two chains. Why not?

  • Because The Merge was technically a soft fork, not a hard fork
  • Because all client teams and the overwhelming majority of the community agreed in advance — no one kept running the old PoW chain
  • Because hard forks never cause network splits
  • Because the Ethereum Foundation forced everyone to switch :::

:::section{mins=2} Your Coins :::

:::lead Planned [[gloss:fork|fork]] — do nothing. Contentious [[gloss:hard fork|hard fork]] — you automatically get coins on both chains. :::

:::p With a planned [[gloss:hard fork|hard fork]], you don't need to do anything. [[gloss:wallet|Wallets]] like MetaMask or Rabby update automatically, exchanges switch their [[gloss:node|nodes]] in the background. Your assets stay the same — the network just runs new rules. Most users only hear about planned forks in the news. :::

:::p A contentious [[gloss:hard fork|hard fork]] works differently. At the moment of the split, your coins exist on both chains simultaneously — because both chains share the same history up to the fork point. One [[gloss:private key|private key]] controls both. If you had 10 ETH before the [[gloss:fork|fork]], you own 10 ETH and 10 ETC after. No transfers needed: the coins on the second chain are already yours. :::

:::p The main danger is acting too quickly. Without proper protection, a [[gloss:transaction|transaction]] sent on one network can be automatically replayed on the other ([[gloss:replay attack|replay attack]]). The best strategy in the first days after a contentious [[gloss:fork|fork]] is to wait and let the situation clarify. :::

:::callout{icon=💡} Imagine a library with two entrances that share the same books up to a certain date. After the split, each entrance gets its own new books. If you had a key before the split — it opens both doors. Your old books are in both libraries. :::

:::keypoints{label="Key Points"}

  • Planned fork: do nothing — automatic for MetaMask users and exchange holders
  • Contentious fork: one private key = both tokens — handle carefully
  • Self-custody advantage: your own wallet guarantees both sides of any contentious fork
  • Exchange: depends on their policy — not all support all fork tokens :::

:::details{badge=Advanced title="Replay Protection, UTXO Splitting & Exchange Policies"} :::p The BTC/BCH fork in 2017 had no built-in replay protection. To safely separate coins, users had to manually create transactions valid on only one chain. For Bitcoin (UTXO model), this is "UTXO splitting": first send BTC to a new address — this creates a UTXO only in the BTC chain. Then handle BCH separately. :::

:::p For Ethereum (account model), it's simpler after EIP-155: chainId is embedded in every transaction signature. The ETH/ETC fork happened before EIP-155, so users at the time were at risk. All new EVM forks get a unique chainId from day one. :::

:::p Exchange policies during contentious forks are unpredictable. Large exchanges usually support both tokens but decide timing themselves. Some freeze withdrawals during the fork. Smaller tokens may not get listed at all. If getting both sides of a fork matters to you — hold funds in your own wallet before and during the event. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-1-5-s6 correct=1 explanation="Correct. After a [[gloss:hard fork|hard fork]], both chains share the same history up to the fork [[gloss:block|block]]. Your [[gloss:private key|private key]] is valid on both. Self-custody (hardware wallet) guarantees you receive both coins automatically. Exchange policies vary — some credit late or never."} You hold ETH on a hardware wallet when a contentious hard fork happens. What do you get?

  • You must choose which chain to follow and lose funds on the other
  • Automatically coins on both chains — the same private key controls both
  • Nothing — you need to transfer to an exchange before the fork to receive both coins
  • Only the new coin — the old one is burned during the fork process :::

:::section{mins=1} Checklist :::

:::lead The action plan depends entirely on which type of fork it is. :::

:::p What you do during a fork depends entirely on its type. Most forks require no action — they happen invisibly in the background. Your wallet updates itself, exchanges switch nodes, balances and transactions continue as before. You typically learn about such forks only through news. :::

:::p Things are different with a contentious [[gloss:hard fork|hard fork]] that creates a new token. There's value at stake, and these moments are when users most often make expensive mistakes: sending [[gloss:transaction|transactions]] without [[gloss:replay attack|replay protection]], clicking phishing links disguised as "urgent updates," trusting exchanges that later refuse to support the new token. :::

:::p The most important rule is: don't rush. Forks don't disappear. New tokens can be claimed weeks after the split. Rushing creates errors, and errors in blockchain are irreversible. All the practical steps below come down to a single principle: wait for the network to stabilize, then act with intention. :::

:::keypoints{label=Checklist}

  • IF IT'S A PLANNED HARD FORK (Dencun, Shanghai, Pectra)
  • ✅ Do nothing — MetaMask and exchanges update automatically
  • ✅ Just wait — it happens without you noticing
  • ✅ In self-custody: make sure your wallet app is updated before the fork block
  • IF IT'S A CONTENTIOUS HARD FORK (new token appears)
  • ⚠️ Don't send transactions right after the fork — wait 24–48h for the network to stabilize
  • ✅ Check if [[gloss:replay attack|replay protection]] (chainId) is in place — without it one signature works on both chains
  • ✅ Check your exchange's policy — will they credit the forked token?
  • ✅ To claim both sides — hold coins in self-custody (not on an exchange) before the fork
  • ✅ After stabilization — coin split: send to separate addresses on each chain before transacting freely :::

:::keypoints{label="Key Points"}

  • Most forks require zero action from you — wallets and exchanges handle planned upgrades automatically in the background
  • The golden rule for a contentious fork is to wait. Forks don't expire. Rushing in the first hours is how people lose money to replay attacks and scam sites
  • If you want to receive both tokens from a contentious fork, hold coins in self-custody before the fork — exchanges may freeze withdrawals or refuse to credit the new token at all
  • Update your wallet and node software only from official sources. Fork announcements are a favorite vector for phishing attacks disguised as urgent updates :::

:::details{badge=Advanced title="UTXO Splitting, chainId Verification & Fork Hygiene"} :::p For [[gloss:bitcoin|Bitcoin]]-style UTXO chains: after a contentious [[gloss:fork|fork]], your coins exist as identical UTXOs on both chains. A "coin split" separates them cleanly. The safest method: send a small amount to a new address on chain A. This creates a UTXO only on chain A. Now your remaining coins on chain A are provably separate from your coins on chain B. Only then start transacting freely. :::

:::p For [[gloss:ethereum|Ethereum]]-style chains: EIP-155 chainId protection is now standard. Before any [[gloss:transaction|transaction]], verify in your [[gloss:wallet|wallet]] that the chainId matches the network you think you're on. Common values: Ethereum mainnet = 1, Ethereum Classic = 61, Arbitrum = 42161, Polygon = 137. A mismatch means your transaction won't broadcast where you expect — or worse, will replay on a chain you didn't intend. :::

:::p Fork hygiene checklist: (1) Download [[gloss:node|node]]/[[gloss:wallet|wallet]] updates only from official repositories, verify signatures where possible. (2) Never sign [[gloss:transaction|transactions]] from emails or messages claiming to be about the [[gloss:fork|fork]] — these are phishing. (3) On the fork day, keep non-essential coins in cold storage. (4) Wait at least 24–48 hours after the fork before making any non-urgent transactions — this lets replay protection activate and scam activity die down. ::: :::

:::quiz{id=q-1-5-s7 correct=2 explanation="Correct. Exchanges may or may not support the new token, and even if they do, they often freeze withdrawals for days. If the new token matters to you, self-custody before the fork is the only way to guarantee access to both sides. But don't rush transactions immediately after — wait for replay protection to activate."} A contentious hard fork is announced for tomorrow. Your coins are on a centralized exchange. What's the safest action to take today?

  • Sell everything — forks always crash the price
  • Do nothing — the exchange will automatically credit both tokens
  • Move coins to your own wallet before the fork, if receiving the new token matters to you
  • Send transactions right after the fork to test if the new chain is working :::

:::callout{icon=💡} Fork preparation is like a flight checklist. You don't improvise at 30,000 feet. The steps are the same every time — but only if you follow them before takeoff, not after. :::

:::further{label="Further Reading"}