Did you know? A blockchain can undergo a major software-rule change and continue as one network—or end up with two separately maintained chains if important groups refuse to follow the same rules. The word *fork* describes a change in rules or history, but not every fork produces a permanently separate cryptocurrency.
Imagine a fictional school science club sharing one ledger and rulebook. The committee proposes changing how new pages must be validated. Alicia updates her copy of the rules, but Kai Kai keeps the older rules because he disagrees with the decision. Tricia now observes that the two groups may accept different future pages even though they agree about most earlier records.
This is the key idea behind a hard fork. A change to consensus rules can make some blocks valid under new software even though older rule-following software would reject them. If enough participants coordinate on the new rules, the network can upgrade without a lasting split. If groups maintain incompatible rules and keep their own histories, two different chains can persist.
Quick answer: a blockchain hard fork is a change in consensus rules that is not backward-compatible with older validating software in the relevant respect. A persistent chain split can occur when different groups continue supporting incompatible versions after the point of divergence. Both chains may share an earlier history but develop different later blocks, assets, governance and market values. A routine planned hard fork does not necessarily create a second lasting chain.
This guide explains how blockchain technology works through consensus changes, full nodes, incompatible rules, Ethereum history, chain identifiers, replay protection and the limits of the phrase “free coins.” It is purely educational and requires no real wallet or digital assets.
Choose Your Reading Route
- A software upgrade is not automatically a permanent split
- What makes a change a hard fork?
- Why full nodes matter when rules change
- A fork at one block can create two future histories
- Ethereum’s 2016 DAO-related split
- A scheduled upgrade may still be called a hard fork
- Do balances get copied at the fork point?
- Frequently asked questions
- Primary sources and further learning
A software upgrade is not automatically a permanent split
Ordinary software applications receive upgrades that improve security, add features or correct mistakes. A blockchain also needs changes, but independently operated nodes must agree on how to recognise valid history under the new protocol rules.
Imagine every science-club student receives a new rulebook and agrees to use it from Monday. The rules change, but the club still maintains one accepted ledger. That resembles a coordinated consensus upgrade without a lasting disagreement about the accepted chain.
Now imagine half the class continues using the old rules and half applies the new ones. If the change creates genuinely incompatible validity conditions and both groups keep maintaining separate histories, the club can develop two distinct records.
The precise outcome depends on consensus details, actual block content, software adoption and participant choices. A hard-fork software release is not itself a guarantee that two economically meaningful networks will survive.
The Ethereum governance documentation explains that protocol upgrades use forks and that unresolved disagreement can lead to incompatible chain histories. The difference between coordinated adoption and contentious disagreement is central.
The important reader question is did the rules change, and did participants ultimately converge on one history or continue maintaining two?
What makes a change a hard fork?
A hard fork alters consensus validity rules in a way that is not backward-compatible with older validating software for relevant newly permitted behaviour. Old clients following the previous rules may reject blocks considered valid under the upgraded rules.
A soft fork generally tightens the set of permitted structures or behaviours so that some older nodes can still regard the new valid blocks as acceptable under their earlier rules, subject to important technical nuances.
The definitions are about rule compatibility, not whether a new logo, token or website appears. A project can launch an unrelated blockchain and call it a fork for promotional reasons, but its actual technical relation to the original needs evidence.
Ethereum’s EIP classification document describes hard forks and soft forks in terms of changes to consensus-layer validity. It is useful for understanding the vocabulary, though the precise effects depend on the underlying protocol.
For the classroom, a hard-fork-like rule could allow a page structure the old rulebook categorically refuses to accept. A soft-fork-like change could add a restriction that still leaves its accepted pages compatible with the older broader rules.
The beginner lesson is to identify which formerly accepted or rejected states change validity under the new protocol. That is more informative than assuming a fork means an automatic second digital coin.
Why full nodes matter when rules change
A fully validating node follows its chosen consensus rules. It checks proposed blocks and transactions under those rules, rather than simply trusting whichever miner, validator or company claims to operate the official network.
If its software does not recognise a new rule, it may reject a block produced under the upgraded protocol. That can cause operators using incompatible versions to disagree about the current accepted chain.
A miner or validator can propose blocks, but it cannot generally compel an independently validating node to accept a block contrary to that node’s configured consensus rules. Network governance therefore involves software choices as well as producers’ behaviour.
Imagine Kai Kai’s classroom node uses an old rulebook and Tricia’s uses a new one. The students cannot resolve their disagreement merely by showing a large vote count on a website. They must agree on which validation rules their shared ledger is supposed to follow.
This helps explain why coordinated upgrade announcements identify activation conditions and compatible client releases. A good operator evaluates the official specification and network version before assuming everything will remain compatible.
Read What Happens When a Blockchain Node Goes Offline for the distinction between the network, validating software and a wallet’s chosen data provider.
A fork at one block can create two future histories
Suppose the fictional club agrees on pages 1 through 100. After the rules dispute, Alice’s group produces page 101A under rule set A while Kai Kai’s group produces page 101B under rule set B.
If the groups permanently maintain different incompatible rule sets, the shared earlier pages become the common ancestry of two records. Future pages and balances can evolve separately. One group’s later transactions do not automatically modify the other’s history.
In a real blockchain, blocks link to predecessors through cryptographic commitments. A split can be visualised as one trunk with two branches beginning after some shared historical point.
This is not equivalent to a temporary reorganisation in which one network’s fork-choice algorithm selects a different recent branch under the same consensus rules. A persistent hard-fork split involves an enduring divergence in the rules or communities supporting the chains.
A user could therefore see different balances on two networks after the split, even where certain earlier transactions exist in both historical records.
The key question is whether this is a temporary dispute over a recent head or a lasting network split under incompatible validity rules. The explanations and risks differ significantly.
Ethereum’s 2016 DAO-related split
A well-known historical example is the Ethereum DAO-related fork in 2016. After a major exploit affecting The DAO, the community debated how the chain should respond. A protocol change was adopted by one group, while another group continued following the alternative history without that change.
The resulting networks became known as Ethereum and Ethereum Classic. They share earlier historical origins but have separate subsequent histories, communities and assets.
This is important because it demonstrates the technical and social sides of blockchain governance. The code change mattered, but so did which miners, node operators, users and economic participants chose to support each history.
The Ethereum governance overview recounts the DAO fork and explains why disagreement can create a chain split. Its account is an introductory summary, not a claim that all participants agreed about the decision.
Students can fairly discuss competing principles in this example: protecting affected users, preserving predictable rule enforcement, respecting community consensus and limiting exceptional interventions. Those values can pull in different directions.
A good historical explanation recognises the trade-offs rather than declaring every fork decision automatically correct or illegitimate.
A scheduled upgrade may still be called a hard fork
Ethereum protocol upgrades have often been called hard forks because they change consensus rules in ways requiring supported clients to adopt the new behaviour. Yet a well-coordinated upgrade can leave one dominant continuing canonical network.
A reader who sees the words “hard fork scheduled” should not automatically expect a second long-lived cryptocurrency to appear in their wallet. The term describes the kind of protocol rule change, not a guaranteed economic split.
Likewise, a protocol’s name or upgrade code name does not independently prove adoption. A specification can be published or proposed before the network activates it under the relevant process.
Ethereum’s consensus specifications list deployed and proposed upgrades in their own documented states. The distinction between agreed rules and experimental future changes is essential for accurate technical reporting.
A classroom analogy is a revised school rulebook scheduled for the next term. The mere publication of the rulebook does not establish that two schools now exist.
For readers, ask which change was proposed, which software supports it, when activation occurs and whether any incompatible minority chain actually persists.
Do balances get copied at the fork point?
When two chains share a historical prefix, some balances and contract state can initially have corresponding values at the split point, depending on the chain design and the fork mechanism. That can create confusion when a wallet displays familiar addresses in both environments.
Suppose Alicia holds twenty imaginary ART units in the club register before the split. Each branch may begin with records reflecting that earlier history. After the split, Alicia’s activity on branch A and branch B is independent unless a separately designed connection exists.
The two sets of assets are not automatically economically interchangeable. Each chain may have a different market, issuer obligations, security model and user demand.
A wallet account using a similar address format can view two chain states without those states becoming one combined balance. Sending on one chain does not automatically settle an invoice on the other.
Readers should avoid treating the phrase “coins duplicated” as guaranteed new wealth. Technical duplication of certain ledger claims is not the same as liquid real-world purchasing power.
For the related network-identity issue, see Why Testnet Tokens Are Not Real Money. Different networks can show similar-looking units while representing separate claims.
Why replay protection matters
A replay risk can arise when signed transaction data valid on one chain may also be valid on another related chain. This can become relevant when networks share historical structure or signing rules but are intended to process later actions independently.
Users may intend a transfer only on one chain and not expect a similar authorised action on another. Chain-specific signing context or other replay-prevention rules help separate those intentions.
Ethereum’s EIP-155 introduced chain-identifier-based replay protection for applicable transaction formats. That is a good example of how protocol design can bind authorisation to a particular network context.
The concept does not mean that every transaction from every fork can always be replayed. Modern networks and transaction formats have different signing and validity constraints. The actual risk depends on those details.
Imagine Alice signs a school payment form intended only for branch A of the club. If branch B blindly treats the identical form as authority, the student could face an unintended second action. A branch label checked under agreed rules can help prevent that confusion.
The educational rule is a signature’s intended network context matters. An account address by itself is not a complete transaction-authorisation story.
What happens to smart contracts after a split?
When a fork preserves corresponding historical state, some contracts may exist at related addresses on both resulting chains. Their later execution can still diverge because transactions, market conditions, network rules or upgrades differ.
A contract that depended on a specific price oracle, off-chain operator or token issuer may be supported on only one branch. A technically present contract is not automatically useful or redeemable on every chain.
Suppose the fictional school booking system is copied into branch B, but the official school administration commits to honouring only branch A tickets. A token that still exists in branch B may no longer confer the same real-world admission right.
This distinction matters for stablecoins, wrapped assets and institutional credentials. The original issuer’s obligations are not necessarily duplicated merely because the ledger state shares history.
A smart-contract explorer could show the same source code on both chains while different authorities, values and events affect its actual results.
The important lesson is that protocol state, off-chain commitments and economic support can split in different ways. Code identity is not legal identity or guaranteed redemption.
Why the two chains can have different prices
After a persistent split, the networks’ native assets or related token claims may trade in distinct markets. Buyers and sellers assess each chain’s security, usefulness, liquidity, development, governance and future prospects separately.
A price on chain A is not a guarantee that a token on chain B has the same value. Even when both begin with related historical balances, market participants may favour one chain or regard them as different products.
Imagine the school’s two clubs choose divergent rules. One offers valuable science activities, while the other closes its reward shop. Students may value their credits differently even if both clubs copied the old register at the split.
The same principle explains why chain forks do not produce an automatic free-money windfall. A displayed balance without real liquidity or issuer backing may be difficult to use.
For the market-data issue, read Why the Same Token Has Different Prices on Exchanges and Why Token Market Cap Is Not Cash in the Treasury.
Always identify which asset and chain a quote belongs to before multiplying balances or interpreting prices.
A hard fork is different from a recent block reorganisation
A temporary reorganisation can occur under one continuing set of consensus rules when nodes learn about competing valid recent branches. The network’s fork-choice procedure selects which branch is canonical without necessarily establishing a lasting second ecosystem.
A hard fork changes the protocol validity rules. When incompatible groups maintain separate histories, the division can be persistent and involve different community governance.
The two can look superficially similar on a diagram: both show a branch. But the reasons for divergence and the status of the branches differ.
In a temporary reorg, the displaced block may no longer belong to the accepted history of the continuing network. In a durable hard-fork split, two communities may continue maintaining distinct ledgers as separate networks.
A payment recipient should use the relevant chain’s settlement policy rather than assuming every visible branching event has identical implications.
Read Why a Confirmed Transaction Can Be Reorganised for the related consensus concept.
Who decides which chain is official?
Different people and institutions can support different chains after a disputed protocol change. Software maintainers, validators or miners, node operators, wallets, exchanges, application teams and users can each influence practical adoption under their roles.
No single universal blockchain authority automatically appoints the one true name that every person must use. A particular project’s governance, community convention and market infrastructure may establish which continuing chain it refers to when using a well-known brand.
A financial exchange might list one asset under a familiar ticker and another under a modified ticker. That is its asset-identification decision. It is not a substitute for checking network identifiers, actual chain state and issuer obligations.
Organisations making statements about payments or credentials should specify which chain and asset they recognise. Otherwise users can be misled by two networks that share earlier history and address formats.
The Ethereum Governance guide explains how consensus-rule decisions can involve research, social discussion and participant adoption rather than simply one contract executing a vote.
The useful reader question is which participants support this rule set, which network does my institution recognise and which claims does it agree to honour?
A classroom fork experiment
Write three pages of fictional science-club ledger history and give identical copies to Alicia and Kai Kai. Both agree on the first three pages and their balances.
Now announce a new rule that permits a form of transaction the old rulebook rejects. Alicia updates her copy, while Kai Kai continues with the old rules. Give them a proposed fourth page valid only under the new rules.
Ask which rule set accepts the fourth page. Alice’s does; Kai Kai’s does not. Let each student maintain a separate fifth page under the chosen rules, making the branching history visible.
Next ask whether both groups can use the same initial credit balances yet develop different later balances. They can under the fictional model. Then ask whether a school shop must accept both clubs’ credits as equivalent. That depends on the shop’s agreement, not the mere fact of a shared past.
Finally give the class a paper form signed for branch A and consider what happens if branch B wrongly accepts it. This motivates chain-specific transaction authorisation.
The exercise uses paper, not a live fork. It teaches validity rules, adoption, two histories and the difference between software consensus and economic promises.
Seven questions about a blockchain fork
What rules changed? Identify the specific consensus difference rather than assuming any software update is a separate coin launch.
Is the change backward-compatible? That helps distinguish hard-fork and soft-fork rule changes, subject to protocol details.
Who adopted the change? Nodes and producers following incompatible software may disagree about validity and supported histories.
Did two networks actually persist? A coordinated hard fork can be one continuing network; a lasting split requires separate adoption and histories.
What happened to earlier balances? Shared history can create corresponding state at the fork point without guaranteeing identical later economic value.
Are signatures chain-specific? Applicable chain identifiers and replay-protection rules matter when networks share related account formats.
Which issuer or institution recognises the claim? A copied token balance does not automatically duplicate a legal redemption promise or real-world asset.
The checklist supports careful reading of fork announcements without treating every software upgrade as a promise of new value.
Frequently asked questions
What is a hard fork in blockchain technology?
It is a consensus-rule change that is not backward-compatible with older validators in the relevant respect. It can lead to a split if incompatible communities continue operating separately.
Does every hard fork create two cryptocurrencies?
No. Many coordinated network upgrades involve hard-fork-style rule changes without a permanent economically meaningful second chain.
What is the difference between hard fork and soft fork?
A hard fork allows some behaviour that older rule-following nodes would reject; a soft fork typically restricts permitted behaviour in a way compatible with certain old validation rules.
Why did Ethereum and Ethereum Classic split?
The 2016 DAO-related dispute led to different groups following incompatible historical outcomes and continuing as separate chains.
Can both branches share the same earlier history?
Yes. A persistent fork can have a common historical prefix before the paths diverge.
Do my tokens automatically double in monetary value after a fork?
No. Corresponding digital balances do not guarantee buyers, liquidity or identical redemption rights on each resulting chain.
What is replay protection?
It is a mechanism that helps prevent a transaction intended for one chain being accepted as an unintended authorised action on another.
Is a hard fork the same as a reorganisation?
No. A reorg changes the selected recent branch under a chain’s consensus process; a hard fork changes consensus validity rules and may create a persistent network division.
Does the same contract code mean the same asset on both chains?
Not necessarily. Contract state, governance, oracle support, issuer obligations and markets can diverge.
Who names the two resulting networks?
Communities, software developers, services and other participants establish conventions and supported asset identifiers. A user should verify the precise network rather than rely solely on a familiar brand.
Can a hard fork be planned without disagreement?
Yes. A coordinated planned upgrade can change the rules under a broadly adopted schedule and retain one continuing accepted chain.
What should students remember?
A hard fork changes the rulebook. A permanent split happens only if incompatible rulebooks continue to have their own supported histories.
Primary sources and further learning
Ethereum Governance explains protocol upgrades, community disagreements and the 2016 DAO-related split. EIP-4 Classification defines hard-fork and soft-fork changes to consensus validity. EIP-155 documents chain-specific replay protection, and Ethereum Consensus Mechanisms explains the distinction between chain selection and block validity.
Within eduKateSG, continue to Blockchain Upgrades: Test Rule Compatibility Before Claiming Adoption, Why a Confirmed Transaction Can Be Reorganised, Why Testnet Tokens Are Not Real Money and Why a Blockchain Address Is Not a Verified Identity.
The lasting lesson is follow the actual consensus rules, chain history, adopted software and economic obligations separately. A fork is not just a new logo or a second price chart.