A blockchain fork is a change, divergence or split in the rules or history of a blockchain network that can cause different nodes to follow different versions of the blockchain. The term can describe several situations, so it is important to distinguish protocol changes from temporary competing chains.
A fork can occur when developers modify consensus rules, when a community disagrees about protocol changes, or when two valid blocks are produced close together and different network participants temporarily follow different branches. In software terminology, a fork can also refer to a new project created by copying an existing codebase, but in blockchain discussions the term usually concerns divergent blockchain histories or protocol rules. Forks are a normal possibility in distributed systems because agreement among independently operated participants depends on common software and consensus rules.
A soft fork is a protocol change that tightens or restricts the set of transactions or blocks considered valid under the new rules while generally allowing nodes running older software to continue recognising blocks produced under the updated rules, provided the relevant compatibility conditions are met. Bitcoin's Segregated Witness, commonly called SegWit, was implemented as a soft fork and changed transaction and block handling while remaining compatible with the existing network under its consensus design. Soft forks can still have complex coordination requirements because miners, nodes, wallets, exchanges and other participants need to understand the change and its implications. Whether a particular change is genuinely backward-compatible depends on the exact consensus rules rather than the label alone.
A hard fork changes consensus rules in a way that can make blocks valid under the new rules invalid under the old rules or vice versa. If participants do not all upgrade or agree on the new rules, the network can split into separate chains that share a common historical point but subsequently develop independently. Ethereum's 2016 DAO-related protocol intervention resulted in Ethereum and Ethereum Classic following separate histories after the divergence.
Bitcoin Cash was created in 2017 following a disagreement over scaling and block-size policy, producing a separate blockchain history from Bitcoin. These examples illustrate that a hard fork can be both a technical protocol divergence and a social or governance event involving disagreements among developers, miners, businesses and users.
Not every fork creates a permanent new cryptocurrency. Temporary forks can arise when two miners or validators produce competing blocks that satisfy the protocol rules before the network converges on one branch. In Proof-of-Work systems, subsequent blocks and accumulated work help determine the canonical chain according to the protocol. In other systems, validator voting and finality rules can resolve competing histories.
Temporary forks can therefore disappear as the network converges, with one branch becoming part of the accepted history and the other becoming stale or otherwise excluded. The exact terminology varies between blockchain systems. A temporary chain reorganisation, commonly called a reorg, can replace previously observed blocks with another valid branch and can therefore affect applications that act before sufficient confirmation or finality.
Forks can be initiated for many reasons, including security fixes, performance improvements, changes to transaction formats, scaling strategies, governance disputes, economic policy disagreements or responses to attacks. Developers may propose a change to correct a vulnerability or add functionality, while communities can disagree over whether the change aligns with the project's goals. In decentralised networks, there may be no single authority capable of imposing a protocol change on every participant. Instead, software developers publish updated implementations and participants choose which software and rules to run. Exchanges, wallets, miners, validators, infrastructure providers and users can all influence the practical outcome because their support determines which chain receives economic and technical activity.
Forks can affect ownership and asset handling in complicated ways. If a blockchain permanently splits into two networks, addresses and historical balances can sometimes exist on both chains from the common point onward, depending on the fork's technical design. This can create what is sometimes described as a duplicated balance, although the two resulting assets are independent after the split and can acquire different market values.
Users must be careful because replay attacks can potentially cause a transaction broadcast on one chain to be valid on another if replay protection is absent. Wallets and exchanges may temporarily suspend deposits and withdrawals around major forks while they assess technical and operational risks. A fork therefore does not automatically mean that every holder can safely transact on both resulting networks without taking additional precautions.
Forks demonstrate that a blockchain is not simply a static database but a shared protocol implemented by independent participants. The code defines technical rules, but the social and economic ecosystem determines which implementation gains practical adoption. This means that protocol governance, developer coordination, validator or miner participation, application support and market liquidity can all influence the significance of a fork.
A blockchain can also undergo routine software upgrades without creating a permanent chain split if participants coordinate on the same new rules. Consequently, the existence of a code change should not automatically be described as a forked blockchain; the important issue is whether the change creates divergent consensus rules or histories.
A blockchain fork is therefore best understood as a divergence involving blockchain protocol rules or competing chain histories. Soft forks generally tighten rules while seeking backward compatibility, hard forks introduce rule changes that can produce incompatible histories, and temporary forks can occur naturally when competing blocks are produced before consensus converges. Permanent forks can result from technical upgrades or community disagreements and may create independently operated networks. Understanding a fork requires examining the exact protocol change, compatibility properties, point of divergence, consensus mechanism, participant coordination and practical consequences for transactions and assets rather than treating every software update as a fork.
