A hard fork is a change to a blockchain's consensus rules that is not backward compatible. Nodes that do not upgrade reject blocks made under the new rules. The Bitcoin developer glossary calls it "a permanent divergence in the block chain", which "commonly occurs when non-upgraded nodes can't validate blocks created by upgraded nodes that follow newer consensus rules." If everyone upgrades, the network simply moves to the new rules. If a group keeps running the old software, the chain splits in two and both versions share the same history up to the fork block.
The latest example: Ethereum's Glamsterdam upgrade (October 2026)
Glamsterdam is Ethereum's next network upgrade. Its specification is EIP-7773, titled "Hardfork Meta - Glamsterdam". As of 25 October 2026:
- Sepolia testnet: activated on 6 October 2026 at 13:53:36 UTC (epoch 353,024), according to the Ethereum Foundation's testnet announcement.
- Hoodi testnet: activation was scheduled for 26 October 2026 at 17:42:48 UTC. On 22 October 2026 the Ethereum Foundation postponed it and said "a new activation date has not been set."
- Mainnet: no date. The Foundation says the Hoodi and mainnet activation dates "have not yet been decided."
EIP-7773 lists 18 EIPs for inclusion and is still in "Review" status. The two headline changes are enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928). The upgrade also reprices gas, including EIP-8037 and EIP-8038. The Foundation's instruction to node operators shows what a hard fork asks of them: "Node operators must update both their execution and consensus layer clients before activation." Nodes that do not update cannot follow the upgraded network.
Hard fork vs soft fork
Both change the consensus rules. The difference is how they treat old software.
| Hard fork | Soft fork | |
|---|---|---|
| Rule change | Allows something the old rules rejected, or changes the rules in a way old nodes cannot validate | Makes only some previously valid blocks or transactions invalid (tightens the rules) |
| Non-upgraded nodes | Reject new blocks and fall off the upgraded chain | Still accept new blocks as valid |
| Backward compatible | No | Yes |
| Risk of a lasting split | Yes, if part of the network does not upgrade | Lower, because old nodes keep following the chain |
The Bitcoin glossary defines a soft fork as "a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid", and adds: "Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible."
Bitcoin's two biggest recent upgrades were soft forks:
- SegWit (BIP141): labelled "Consensus (soft fork)." Nodes that did not upgrade "will not see nor validate the witness data" and treat witness programs as anyone-can-spend scripts. That is why older software kept working.
- Taproot (BIP341): also a soft fork. According to the BIP, "the deployment did activate at height 709632 on Bitcoin mainnet."
A plain "fork" is not the same thing either. In the Bitcoin glossary, a fork is when two or more blocks have the same height, usually because miners find blocks at nearly the same time. These short-lived forks resolve themselves within normal operation.
Does a hard fork ask anything of you?
Answer up to three questions to see what a hard fork means for your coins, your node or your wallet.
Is part of the network staying on the old rules, so the chain splits in two?
- No, everyone upgrades (a planned upgrade with no dissenting group) → next question
- Yes, the chain splits → next question
Do you run a node or validator yourself?
- Yes, I run a node or validator → Upgrade before activation
- No, I only use a wallet or service → Usually nothing to do
Do you plan to move coins on either chain after the split?
- Yes, I want to send or receive coins → next question
- No, I am only holding → Your balance exists on both chains
Does the fork have replay protection, as Bitcoin Cash did with SIGHASH_FORKID?
- Yes, replay protection is in place → Move coins, but wait for confirmations
- No, or I don't know → Check replay protection before moving coins
A planned hard fork means you must upgrade before the activation block or epoch. On Ethereum, that means updating both the execution and consensus clients; nodes that do not update cannot follow the upgraded network.
Planned upgrades with no dissenting group, such as Ethereum's regular upgrades, usually need no action from ordinary holders. The work falls on node operators and software providers.
History up to the fork block is the same on both chains, so balances recorded before the fork exist on both. Whether the new chain's coin has any value or support is a separate question.
Replay protection stops a transaction from one chain being rebroadcast on the other. BIP50 shows double spends are possible while two chains compete, so waiting for more confirmations before treating a payment as final is the cautious approach.
Without replay protection, a transaction signed on one chain can be valid on the other. Find out whether the fork has it before you move coins, and wait for more confirmations while two chains compete.
This sorts general cases from the article only: it cannot tell you whether a specific fork will split, what a new chain's coin is worth, or how a given wallet or service will handle it.
Why hard forks happen
- Planned upgrades. Ethereum ships its protocol changes as coordinated hard forks. Examples are Pectra (7 May 2025, block 22,431,084) and Fusaka (3 December 2025, block 23,935,694), both listed on ethereum.org's upgrade history.
- Disputes over the rules. When a community cannot agree, one side can fork away with different rules and form a separate chain.
- Responding to an incident. The 2016 DAO fork moved funds out of an exploited contract.
- Accidents. Software bugs can split a chain when nobody planned a rule change.
Three hard forks that show how it works
The DAO fork, 20 July 2016 (Ethereum)
In 2016 an attack drained more than 3.6 million ETH from an insecure contract called The DAO. ethereum.org records that the community voted and over 85% supported a fork. It activated at block 1,920,000 and moved the funds to a new contract, where affected users could reclaim 1 ETH per 100 DAO tokens. Some miners refused because "the DAO incident wasn't a defect in the protocol." They stayed on the unforked chain, which became Ethereum Classic.
Bitcoin Cash, 1 August 2017
The Bitcoin Cash technical specification set the default activation time to 1 August 2017, 12:20:00 UTC. It raised the block size limit to at least 8,000,000 bytes and required the fork block itself to be larger than 1,000,000 bytes, which the spec says was to prevent a reorganization back onto the original chain. It also added replay protection: after activation, transactions were valid only if they set the SIGHASH_FORKID bit and used a new signature digest. This stopped a transaction from one chain being rebroadcast on the other. Block explorers and press reports place the split right after block 478,558, though they differ by one block on which height to call the fork point.
The accidental fork of March 2013 (Bitcoin)
BIP50 describes a split that no one planned. Bitcoin 0.8 accepted a block that versions before 0.8 rejected, because older versions configured "an insufficient number of Berkeley DB locks." In effect, a database setting had become a consensus rule. The 0.8 chain had about 60% of the hash power, so the split would not resolve on its own. Two large mining pools downgraded to 0.7, which gave the majority of hash power to the other chain, and the 0.8 nodes reorganised onto it. During the split at least one large double spend went through. BIP50 says it was done by someone testing whether it was possible and "was not intended to be malicious."
What a hard fork means for you
- If you hold coins: when a hard fork splits a chain, the history up to the fork block is the same on both chains. Balances recorded before the fork therefore exist on both. Whether the new chain's coin has any value or support is a separate question.
- Replay protection matters. Without it, a transaction signed on one chain can be valid on the other. That is why the Bitcoin Cash specification made SIGHASH_FORKID mandatory. Before moving coins after a split, check whether the fork has replay protection.
- If you run a node or validator: a planned hard fork means you must upgrade before the activation block or epoch. On Ethereum, that means updating both the execution and consensus clients.
- If you only use a wallet or service: planned upgrades with no dissenting group, such as Ethereum's regular upgrades, usually need no action from ordinary holders. The work falls on node operators and software providers.
- During any split, be careful. BIP50 shows that double spends are possible while two chains compete. Waiting for more confirmations before treating a payment as final is the cautious approach.
Limitations: dates and figures come from project documentation as of 25 October 2026. Glamsterdam's testnet and mainnet schedule may still change.
