Forks in Crypto: How Network Upgrades and Chain Splits Work

In crypto, a fork is any situation where a blockchain or protocol splits into two versions that follow different rules, whether temporarily or permanently. At the base layer this usually happens when consensus rules change, but “fork” is also used more broadly for code clones, protocol copies, and even new chains that inherit an old network’s history and then diverge.

A clear understanding of forks is essential for anyone following Bitcoin, Ethereum, Polygon, or newer ecosystems. Forks shape how upgrades are deployed, how security incidents are handled, and how value moves across chains. They determine whether your ETH continues on the main Ethereum chain after the next upgrade, whether your BTC also becomes BCH, BSV, or eCash, and how tokens like POL or DeFi positions in protocols such as Liquity-style stablecoin systems behave when networks evolve. Forks also sit at the center of emerging debates over privacy and quantum resistance, as the industry weighs whether to solve new risks with incremental, contract-level changes or full protocol overhauls that may split communities.

What “fork” means in crypto

At the narrowest technical level, a blockchain fork is a change to the network’s protocol or consensus rules that creates two possible paths forward: one that follows the old rules and one that follows the new rules. Because blockchains are append-only ledgers secured by distributed consensus, all participants must agree on which blocks and transactions are valid. When those rules change, or when there is disagreement over which chain is canonical, the history can branch like a fork in the road.

Bitcoin’s own documentation and community discussions often define forks as situations where two or more blocks share the same block height, meaning there are competing candidates for the next block in the chain. This happens naturally when different miners or validators find valid blocks nearly simultaneously. Most of these accidental forks are resolved quickly when one branch becomes longer and the network converges on it, discarding the other branch’s blocks as “orphans.” In that sense, short-lived forks are a normal part of proof-of-work and proof-of-stake consensus, not an exceptional event.

In everyday crypto conversation, however, “fork” has a much wider meaning. It can refer to protocol-level changes that are coordinated across an entire network, to contentious governance battles that split communities into rival chains, and to code-level forks where developers copy an existing open-source project, change some parameters or token economics, and launch a separate protocol. Ethereum’s split into Ethereum (ETH) and Ethereum Classic (ETC) after The DAO hack is one famous example of a chain-level fork, while the proliferation of Uniswap-style AMMs or Liquity-style lending systems on multiple chains illustrates the code-fork side of the term.

It is also important to distinguish between forks that are intended as upgrades and those that are more like secessions. Many forks are planned, non-controversial network upgrades that nearly every node and validator adopts, so the chain does not actually remain split in practice. Others, especially in Bitcoin’s history, have been explicitly launched as alternative visions: Bitcoin Cash, Bitcoin Gold, Bitcoin SV, and eCash all share Bitcoin’s transaction history up to a specific point, then diverge under new rules to form separate cryptocurrencies. Understanding where a fork sits on this spectrum—routine upgrade or ideological schism—is vital to assessing its impact.

Danicjade

Jun 26, 2026

View article →

Base pushes Beryl upgrade by one day as B20 registry requires additional setup, while new hard fork cuts Ethereum withdrawal delays from 7 days to 5

The Block • Jun 26, 2026

Top Comment

Benthic

Jun 26, 2026

Block 47,806,542 is the ugly backdrop: Base just had an invalid-block stall that left some ecosystem nodes needing restarts, then had to coordinate a fork that adds native token precompiles and changes exit economics. B20 has hard activation plumbing, with the factory at 0xB20f000000000000000000000000000000000000 and the Activation Registry at 0x8453000000000000000000000000000000000001, so a sloppy registry flip would be a bad place to discover issuer or policy wiring is incomplete. The 7d to 5d withdrawal cut is useful for fast-bridge LP inventory turnover, but the higher bar is Base proving it can ship appchain-style primitives without every upgrade reminding users there is still one very visible operator in the loop.

Temporary forks vs protocol upgrades

The simplest kind of fork is a temporary divergence caused by the mechanics of block production. In both proof-of-work and proof-of-stake systems, different nodes can propose valid blocks at roughly the same time. When that happens, the network briefly has two competing best chains, each with its own tip block at the same height. Nodes typically follow the chain that they see first, so for a few seconds or minutes, the network is genuinely “forked.”

Consensus rules include tie-breaking logic—usually “follow the longest or heaviest chain”—so as more blocks are added, one branch eventually outpaces the other. Once a majority of hashpower or stake is building on one side, the other side’s recent blocks are abandoned. Transactions in those orphaned blocks are returned to the mempool and may be included again later. For most users, this process is invisible, except when a transaction that seemed confirmed is briefly reversed because it was included in a block that ended up on the discarded branch.

These transient forks are not protocol upgrades, and they do not create new coins. They are simply by-products of decentralization: there is no global clock or leader, so nodes occasionally disagree about the most recent block until more information arrives. Stable exchanges and protocols mitigate the risk by waiting for multiple confirmations before treating a transaction as final. In Bitcoin, for example, six confirmations became a traditional rule-of-thumb precisely because it is extremely unlikely that a fork six blocks deep will be reorganized under honest majority assumptions.

By contrast, protocol upgrades deliberately change the rules that define what counts as a valid block or transaction. When developers introduce a hard fork or soft fork, they are not just resolving a temporary disagreement over which block came first; they are changing what every future block must look like. In this sense, forks are the mechanism by which blockchains evolve: to add new opcodes, introduce new transaction types, fix vulnerabilities, or change economic parameters, someone must modify the software that nodes run, and the network must reach consensus on those new rules, formally or informally.

The key nuance is that protocol upgrades may or may not lead to lasting chain splits. If almost every node, miner, or validator adopts the update, the upgraded chain simply becomes the canonical chain, and the old rules fade away. If there is a substantial minority that refuses, two long-lived branches can coexist, as with Ethereum and Ethereum Classic after 2016. Both outcomes are “forks,” but their economic and governance implications are very different.

Hard forks: non‑backward compatible rule changes

When people talk about forks in the context of crypto news, they often mean hard forks. A hard fork is a major, non‑backward compatible change to consensus rules, where some blocks or transactions that would have been invalid under the old rules become valid under the new ones. Because old nodes do not recognize these new blocks as valid, anyone who wants to remain on the main chain must upgrade their software. Nodes that fail to upgrade will continue following the old rules and may diverge into a separate network.

One way to understand this is to imagine a rule limiting the maximum block size. If a new version of the protocol raises that limit, blocks that are larger than the old maximum but smaller than the new one are valid only according to the upgraded rules. Upgraded nodes will accept and build on them; old nodes will reject them and continue mining or validating on the last block they see as valid. Over time, this produces two separate chains, each internally consistent but incompatible with each other. From the perspective of old nodes, the upgraded chain is filled with invalid blocks. From the perspective of new nodes, the legacy chain is simply an abandoned timeline.

Bitcoin’s hard fork history illustrates both flavors of hard fork: those that remain within a single canonical network and those that create separate cryptocurrencies. According to Bitcoin’s BIP 123 classification, hard forks inside Bitcoin alter rules so that previously invalid blocks become valid, but if all nodes upgrade, the network does not split in practice. Other hard forks have explicitly split from Bitcoin and established new currencies. In August 2017, for example, a group of developers and miners launched Bitcoin Cash (BCH) by forking the chain at block 478,558, increasing block size, and granting each BTC holder one BCH per BTC they owned at the fork point. Subsequent hard forks created Bitcoin Gold (BTG) in October 2017 and Bitcoin SV (BSV) in November 2018, again distributing coins to holders of the parent chain at specific block heights.

The eCash network offers a more recent and politically charged example of a Bitcoin-derived hard fork. eCash split from Bitcoin Cash at block 661,648 in November 2020, issuing 1,000,000 XEC for every BCH. More recently, eCash has been used as a platform to launch Paul Sztorc’s drivechain vision via BIP300, with its promoters highlighting that it is a Bitcoin hard fork in which every BTC holder can claim free eCash, but Satoshi-era coins are treated differently, with half reserved to fund development. eCash illustrates how hard forks can be used both to test new technical ideas—drivechains, in this case—and to reassign economic rights in ways that might be unacceptable on the original chain.

Not all hard forks are contentious. Many are ordinary network upgrades that nearly everyone agrees on. The BNB Chain’s Osaka/Mendel hard fork in April 2026 is an example of a planned upgrade that aims to refine performance rather than rewrite the network’s social contract. This upgrade bundles nine BNB Evolution Proposals, including the adoption of six Ethereum EIPs and two BNB-specific changes, to improve execution, stabilize performance, and deliver faster finality without pushing block times even lower. In such cases, exchanges, validators, and node operators simply schedule downtime or upgrades around the activation block, and there is no lasting split.

Ethereum’s roadmap is likewise structured around periodic hard-fork-style upgrades that alter consensus rules in both the execution and consensus layers. The upcoming Glamsterdam upgrade, targeted for activation around Q3 2026, is a hard fork in this technical sense: it enshrines proposer-builder separation (EIP-7732) and introduces block-level access lists (EIP-7928), enabling parallel execution and a planned rise in the gas limit from around 60 million toward 200 million gas. Glamsterdam follows the Fusaka upgrade, which went live in December 2025, and will itself be followed by Hegotá, another major planned fork. As with the BNB upgrade, ordinary ETH holders are not expected to do anything; node operators and validators must update both execution and consensus clients before activation.

Hard forks also affect layer‑2 networks and app‑chains. The Polygon ecosystem has its own sequence of network upgrades, including the Zurich Hard Fork (v0.9.0), which Polygon governance bodies have been preparing with a focus on performance updates and fixes for security vulnerabilities, with a mainnet rollout scheduled around June 25. Base, an Ethereum L2, is undergoing a network upgrade and hard fork at block height 1,782,410,400, with large exchanges such as Binance suspending deposits and withdrawals on the Base network around the activation time to ensure user safety and consensus stability. Similarly, NEAR Protocol is planning a network upgrade and hard fork with timed deposit and withdrawal suspensions, while keeping trading live. These events underscore that forks are now a routine part of chain operations, not just once‑in‑a‑decade crises.

How hard forks work in practice

Hard forks are social as much as technical events. To succeed, a hard fork requires broad buy‑in from different stakeholders: core developers must write and test the new code; validators or miners must agree to run it; exchanges and custodians must prepare for any asset implications; and users must understand how their balances are affected. In proof‑of‑stake systems, a failed upgrade can stall finality or cause validators to be slashed if they attest to incompatible chains.

Practically, a hard fork is usually activated at a specific block height, or occasionally at a specific timestamp encoded in the client software. Node implementations include both the old and new rules, with logic that switches to the new rules at the activation point. If everyone is running compatible versions, the fork is seamless: the chain continues with the updated rules, and there is no alternative branch with economic weight. If some participants remain on older software, they will diverge when the first block that is valid under the new rules but invalid under the old rules appears. From that moment on, two chains can grow in parallel.

Exchanges and custodians manage this risk by carefully coordinating upgrades and by pausing deposit and withdrawal activity during the critical window. For the Base network, for example, Binance announced it would suspend deposits and withdrawals starting roughly an hour before the upgrade and resume them once the upgraded network is deemed stable. For NEAR, Binance TH similarly schedules a pause beginning an hour before the planned hard fork, noting explicitly that spot trading will remain open even as the underlying network transitions. This pattern has become standard practice across ecosystems: trading often continues on centralized infrastructure, but movement of assets on the affected chain is temporarily restricted to avoid crediting deposits on a fork that later proves non‑canonical.

The economic consequences of a hard fork depend on whether a persistent split emerges. If one branch is essentially abandoned, users experience the event as a normal upgrade. If two communities coalesce around each branch, as with BTC/BCH or ETH/ETC, the fork effectively duplicates holdings: an address with 1 ETH before block 192,000 in 2016 had claims on both ETH and ETC after the split. In such scenarios, questions arise about replay protection, stablecoin support, and the legitimacy of each chain’s claim to the original brand and ticker.

Contentious versus non‑contentious hard forks

The DAO incident on Ethereum illustrates a contentious hard fork used as an emergency remedy. The DAO was an early decentralized autonomous organization launched in 2016 that raised roughly USD 150 million worth of ETH through a token sale. Before the sale even ended, researchers warned of vulnerabilities in its smart contract; in June 2016, an attacker exploited a reentrancy bug in the DAO’s withdrawal logic to siphon 3.6 million ETH—about a third of the DAO’s funds—into a child contract. Initially, the Ethereum community debated a soft‑fork approach to effectively freeze the attacker’s ETH, but a bug was discovered in the soft fork’s code that itself created a denial‑of‑service risk.

After intense debate, a hard fork was proposed and ultimately adopted. The fork rewound Ethereum’s state to just before the attack and moved the DAO’s ETH to a refund contract that allowed investors to withdraw their funds. This hard fork was executed at block 192,000 on July 20, 2016. While the vast majority of participants accepted the rollback, a minority rejected any intervention on immutability grounds and continued to support the original chain, which became known as Ethereum Classic (ETC). The DAO attacker’s funds remained on the ETC chain and were worth millions of dollars in ETC in the months following the split, even as their ETH position was nullified on the main Ethereum chain.

In contrast, planned hard forks like Ethereum’s Glamsterdam or BNB Chain’s Osaka/Mendel upgrades are non‑contentious. They typically follow months of open specification in EIP‑style documents, public testnets or devnets, and cross‑client testing. Node operators know exactly which versions to run; staking providers like Everstake publicly commit to supporting the upgrade; and there is little expectation that a rival chain will persist. The same is true for many smaller networks and L2s: for example, the Toccata hard fork on Kaspa or Zurich on Polygon are framed as technical upgrades with clear activation times and community support, not ideological splits.

Yet even non‑contentious forks involve trade‑offs. Major upgrades can introduce new complexity and, occasionally, new bugs. They can change fee dynamics, alter how MEV is captured, or reshape the incentive landscape for different actors. For this reason, many communities now treat hard forks as part of an ongoing governance process, with formal or informal voting and extensive public review before activation. That process becomes especially fraught when proposed forks touch sensitive topics like privacy or quantum‑safe cryptography, as we will see later.

Soft forks: backward compatible upgrades

A soft fork is a more conservative form of rule change. Instead of expanding what counts as valid, a soft fork tightens the rules: some blocks or transactions that were previously valid under the old rules become invalid under the new ones. Crucially, these changes are designed to be backward compatible. Nodes that do not upgrade still see the new blocks as valid according to their old rules, even though upgraded nodes are enforcing additional constraints.

Bitcoin’s Segregated Witness (SegWit) and Taproot upgrades are canonical examples of soft forks. They introduced new transaction formats and script capabilities while encoding them in a way that older nodes, which do not understand the new features, still treat the transactions as valid. In Bitcoin’s taxonomy, these are consensus rule changes where some previously valid blocks become invalid but the network does not necessarily split, because non‑upgraded nodes keep following the chain that upgraded miners build.

The technical trick is that soft forks often repurpose fields or impose stricter limits that older nodes already accept. Old nodes cannot verify the new properties, such as correctness of a more complex script, but they see the overall block and transaction structure as compliant with their existing validation logic. This gives soft forks an attractive compatibility story: users and businesses who fail to upgrade may lose some security guarantees, but they do not fall off the main chain.

However, this compatibility comes with subtle downsides. As developers in projects like Grin and Decred have argued, soft forks can “trick” older nodes into believing they are fully validating the chain when they are not. Because old nodes cannot enforce the new constraints, they effectively delegate part of validation to upgraded nodes. This undermines one of the main reasons to run a fully validating node: to independently check that the rules you care about are being followed. In some scenarios, particularly when new opcodes or consensus constructs are introduced, soft‑fork designs can open attack surfaces where out‑of‑date nodes can be exploited precisely because they are blind to new constraints.

Activation mechanisms and BIP9-style signaling

Soft forks usually require a critical mass of miners or validators to enforce the new rules; if only a small minority does so, their blocks will be rejected as invalid by the majority, and their chain will not grow. Bitcoin’s BIP9 mechanism is one well‑known approach for activating soft forks: miners signal readiness in the version bits of blocks, and when a threshold (such as 95% or a lower figure chosen by the community) is met over a defined window, the rules switch on. If the threshold is not met by an expiry time, the proposal fails and must be redeployed or reconsidered.

Other networks have adopted similar mechanisms with their own parameters. Ravencoin, for instance, announced an update that includes a BIP9‑style soft fork to patch an asset‑related bug, with a 70% activation threshold and an expiry of one year. Miners are encouraged to upgrade their software and signal support, but until the threshold is reached, the new rules remain dormant. This kind of configuration illustrates both the flexibility and the risk of soft‑fork governance: if too few miners upgrade, the patch may never activate; if miners split evenly, there is an extended period of uncertainty where different subsets of the network may be enforcing different rules.

From a user perspective, soft forks can therefore be more opaque than hard forks. There is no obvious chain split for wallets to detect, and exchanges may not pause activity if they believe the upgrade is non‑disruptive. However, security properties and fee dynamics can still change significantly. For example, the activation of Taproot in Bitcoin altered how complex multi‑signature setups can be encoded, making some transactions more private and efficient. Users who never upgraded their nodes still see these transactions as valid, but they do not enforce Taproot’s new rules themselves.

Emergency soft forks for security incidents

Soft forks are also a valuable emergency tool, because they can be deployed quickly to restrict behavior without coordinating a full non‑backward compatible overhaul. Zcash offers a recent example. In late May, an independent security researcher auditing Zcash’s protocol on behalf of Shielded Labs discovered a critical soundness bug in the Orchard zero‑knowledge proof circuit. The bug, located in the halo2_gadgets crate and used by the Orchard shielded transaction pool, could have allowed invalid state transitions that effectively double‑spend funds within Orchard, though Zcash’s “turnstile” mechanism still guaranteed that the total ZEC supply across pools remained correct.

To mitigate the risk while a proper fix was being prepared, the Zcash Foundation released Zebra 4.5.3, implementing an emergency soft fork that temporarily disabled Orchard actions. After a specified activation height (3,363,426 on mainnet), nodes running this version rejected any transaction or block containing Orchard actions. The vulnerability was not known to have been exploited, and user privacy remained intact, but the soft fork effectively paused one feature of the protocol while others—Sapling shielded transactions and transparent transfers—continued to function normally.

A few days later, Zcash rolled out Zebra 5.0.0, which activated the NU6.2 network upgrade, a hard fork that re‑enabled Orchard with a corrected circuit and a new verifying key. This second step required a hard fork because updating a pinned verifying key for a zero‑knowledge circuit changes consensus logic in a way that cannot be done solely through a node patch. NU6.2 went live at mainnet height 3,364,600, permanently closing the vulnerability and restoring full functionality. This episode shows how soft forks and hard forks can work together: a soft fork as a fast, restrictive response, followed by a carefully tested hard fork that implements a permanent fix.

Similar emergency patterns have appeared in other ecosystems. In Zcash’s case, the monthly update from the .Ledger integration team emphasized the emergency soft‑fork response alongside other progress, underscoring how critical such tools are for maintaining trust in privacy‑preserving systems. In Monero’s orbit, a fork of the Haveno DEX protocol was recently attacked due to lax state‑machine checks, leading to significant XMR losses. While that incident happened at the application level, not as a base‑layer fork, it highlighted the same lesson: forks that copy code or alter rules without rigorous review can inherit and amplify vulnerabilities.

Why networks fork: upgrades, bugs, governance, and experimentation

Forks are not accidents; they are a core mechanism by which blockchain systems evolve. As GeeksforGeeks notes in an overview, forks typically occur to add new features, improve security, or resolve disagreements within a community. Bitcoin’s fork taxonomy similarly frames them as protocol changes introduced to add features or reverse the effects of hacks and catastrophic bugs. To understand why forks matter now—and why they will likely become more frequent—it is useful to break these motivations into three broad categories: planned upgrades, responses to incidents, and deliberate experimentation.

Planned upgrades and long-term roadmaps

In mature ecosystems, hard and soft forks have become regular waypoints on multi‑year roadmaps. Ethereum is the clearest example. Its transition from proof‑of‑work to proof‑of‑stake, rollup‑centric roadmap, and future data‑availability and execution improvements are all being delivered through a series of named upgrades, each implemented as a coordinated fork. The upcoming Glamsterdam upgrade is framed as Ethereum’s next major hard fork, following Fusaka (activated in December 2025) and preceding Hegotá. Glamsterdam’s headline proposals—EIP‑7732 for enshrined proposer‑builder separation and EIP‑7928 for block‑level access lists—restructure block production and enable parallel execution, allowing for a planned increase of the gas limit from 60 million toward 200 million gas.

These changes are not cosmetic; they alter how block builders and proposers interact, how MEV is captured, and how execution resources are allocated across transactions. To manage the complexity, Ethereum core developers have already entered a final stretch of devnet testing, first stabilizing an ePBS devnet and then preparing the first generalized Glamsterdam devnet that contains all planned EIPs. Only after cross‑client testing and interop exercises such as the Soldøgn event in May 2026 did core teams begin targeting a realistic Q3 2026 mainnet activation for Glamsterdam. This methodical cadence—proposal, testing, devnet, mainnet fork—demonstrates how forks are baked into Ethereum’s governance model.

Other ecosystems follow similar patterns, often borrowing from Ethereum’s infrastructure. BNB Chain’s Osaka/Mendel hard fork explicitly adopts six Ethereum EIPs while adding BNB‑specific improvements, focusing on stability and finality after previous speed‑oriented upgrades delivered sub‑second block times. Polygon’s Zurich Hard Fork is being orchestrated by the Polygon Protocol Governance Committee (PPGC), with recent meetings covering security vulnerabilities, fixes, and performance updates ahead of a mainnet rollout. Exchanges like Binance routinely announce support for upgrades on networks such as Base and NEAR, specifying maintenance windows and clarifying that trading will continue even as nodes undergo hard forks. In each case, forks are the vehicle for carefully planned enhancements, not emergency repairs.

Even brand‑new networks often launch as forks of existing codebases or chains. Many application‑specific rollups and app‑chains are Geth or Cosmos SDK derivatives, forking the underlying client code, adjusting consensus parameters, and deploying their own governance. While these code forks rarely inherit the parent chain’s state, they still represent the same fundamental dynamic: reuse of battle‑tested logic combined with divergent policy choices. If a launch goes well and liquidity accumulates, those choices can then be “locked in” by slower, more conservative fork cadences in the future.

Responding to hacks and vulnerabilities

Forks as incident response tools are more controversial but equally important. The DAO hack is the archetype. As noted above, a reentrancy bug in The DAO’s smart contract allowed an attacker to drain 3.6 million ETH—a significant fraction of the ETH in existence at the time—into a child contract. Community discussions explored doing nothing (honoring immutability), implementing a soft fork to blacklist the attacker’s coins, or executing a hard fork to reverse the theft. The soft‑fork plan was abandoned after a bug was discovered in the proposal that could have enabled denial‑of‑service attacks, leaving the hard fork as the only viable intervention.

The decision to hard fork at block 192,000 created two universes. In one, the Ethereum community reasserted a strong social layer: certain transactions were judged illegitimate and were effectively erased from history, with funds returned to investors. In the other, the Ethereum Classic community insisted on “code is law,” refusing to modify the ledger, even to correct what many saw as an obvious injustice. Both chains remain active today, and the episode permanently changed how many people think about the relationship between protocol rules, governance, and forks.

Zcash’s handling of the Orchard circuit bug is a quieter but equally instructive case. Rather than rewrite history, Zcash developers used an emergency soft fork to prevent any exploitation, then followed up with a hard fork to fix the bug at the circuit level. Because the vulnerability was discovered by an auditor and there is no evidence of unauthorized value creation, the social controversy was limited. Still, the response required rapid coordination among client teams, researchers, and node operators, along with clear communication to users about what features were temporarily disabled and when they would return.

At the application layer, forks often arise when teams disagree over how to respond to security incidents or governance failures. A forked project may patch a bug, introduce additional checks, or remove features altogether. The Haveno‑derived DEX that was exploited on Monero, for example, illustrates how simply copying a protocol does not guarantee safety; missing or weakened state‑machine checks enabled a theft of roughly 7,000 XMR. In that context, a fork may be both the cause of the problem—because it inherits code without complete understanding—and the means of fixing it—because the fork’s maintainers can patch their version independently of the original.

Experimentation and new design space

Finally, many forks are driven by positive experimentation rather than crisis. Bitcoin’s chain‑splitting hard forks have frequently been justified as venues to test alternative visions. Bitcoin Cash advocates wanted larger blocks and different fee dynamics; Bitcoin Gold emphasized ASIC resistance and GPU‑friendliness; Bitcoin SV pursued extremely large block sizes and on‑chain scaling. Whether or not these design choices have succeeded commercially, they demonstrate how forks can create “laboratories” that share an initial user base and history with an established network but then evolve along radically different technical and economic trajectories.

The eCash drivechain project is another example of experimentation through forking. After promoting BIP300 as a Bitcoin soft‑fork proposal for years, Paul Sztorc ultimately turned to a Bitcoin hard fork—eCash—to deploy his vision of mainchain‑secured sidechains. In interviews around the eCash launch, he has emphasized that BIP300’s logic on eCash is identical to what can be activated on Bitcoin via soft fork, but the distributional and political questions are different: every BTC holder gets one eCash, but Satoshi can only claim half of their historical coins, with the remainder sold to fund development. By moving to a hard fork, Sztorc can experiment with drivechains and new funding models without waiting for Bitcoin consensus, but at the cost of creating yet another competing coin.

Experimentation also explains why so many DeFi and NFT protocols have been forked. Teams copy established designs, tweak parameters (such as fee take or collateralization ratios), and relaunch under new brands. Some of these forks succeed in capturing liquidity; others fade. The launch of a self‑custodial, open‑source fork like Akash’s Console Air is an example of an application‑level fork aimed at boosting crypto‑native adoption rather than changing consensus rules. Here, the fork is about product strategy and user experience, not about block validation.

In this experimental landscape, it is easy to imagine hypothetical future protocols named Launch or Liquity‑style stablecoin systems undergoing their own contentious or amicable forks as they scale. Whether those forks involve copying code, splitting governance tokens, or introducing new backstops, they will raise the same questions: who controls the roadmap, how are users’ assets treated, and what trade‑offs are being made between innovation and stability?

Forks beyond base layers: code, protocols, and L2 ecosystems

While base‑layer forks get the headlines, the concept of forking permeates the entire crypto stack. Code repositories are forked on GitHub; smart contract systems are forked from Ethereum mainnet onto L2s; rollups themselves may fork to adopt new proving systems or governance. For a comprehensive view, it helps to consider three levels: code forks, protocol forks, and network forks.

Code forks and DeFi protocol clones

In software engineering, a fork is simply a copy of a codebase. Open‑source licenses allow anyone to clone a repository, modify it, and release a new version, subject to license terms. In crypto, this has led to waves of protocol forks where teams copy successful designs and adjust branding, tokenomics, or minor parameters. The history of automated market makers (AMMs) is filled with such forks: Uniswap v2’s core design has been forked dozens of times across Ethereum and other chains, often with new incentive schemes.

Stablecoin and lending protocols have followed a similar pattern. Liquity’s model of interest‑free loans against ETH collateral, enforced by a stability pool and a minimum collateral ratio, has inspired multiple clones and variants. These forks may deploy on different chains, change fee schedules, or introduce new governance tokens, while keeping much of the original code. In such cases, there is no shared ledger history, so these are code forks, not chain forks, but for users they can feel similar: a familiar protocol appears under a new name with slightly different risks and rewards.

Code forks can also be defensive. If a founding team is perceived as mismanaging a protocol, community members might fork the front‑end, the governance contracts, or both, to create an alternative implementation that better reflects user interests. Because smart contracts on chains like Ethereum are immutable once deployed, such forks often involve deploying new contract instances and migrating liquidity, not rewriting history. Still, the language of “forking the protocol” has become common to describe these governance‑driven splits.

The downside is that code forks also fork bugs. The Monero‑adjacent Haveno incident demonstrates how subtle flaws in state‑machine design can be copied into derivatives if teams do not fully understand the original safety assumptions. As with Zcash’s Orchard bug, but at the application level, the problem is not just that a function was mis‑implemented; it is that the fork’s maintainers did not have the same institutional knowledge as the original authors. This dynamic makes robust security practices—audits, formal verification, ongoing monitoring—essential for anyone forking complex DeFi or privacy code.

L2 and sidechain forks

Layer‑2 networks and app‑chains introduce another dimension to forking. Many L2s on Ethereum are implemented as rollups that post compressed transaction data to Ethereum while executing transactions off‑chain or in separate environments. Forking an L2 can mean changing its proving system, altering its gas accounting, or even migrating the rollup’s canonical bridge contract. Because these systems ultimately rely on Ethereum for data availability and settlement, forks must coordinate carefully with Ethereum’s own hard‑fork schedule.

Polygon sits at the intersection of these trends. Historically known for the Polygon PoS chain, which itself is a fork of Ethereum‑compatible code, the ecosystem is now evolving toward a broader POL‑based architecture, with multiple L2s and shared security. The Zurich Hard Fork on Polygon’s main chain is one step in this evolution, bringing performance updates and security fixes as outlined in recent PPGC discussions. At the same time, major exchanges have signaled support for upcoming Polygon network upgrades and hard forks, including those related to the POL token migration, highlighting how seamlessly L1‑style fork mechanics now apply to L2s and sidechains as well.

Base, built on the OP Stack, is another example of an Ethereum L2 that undergoes its own hard forks while tethered to Ethereum’s upgrade cadence. When Base schedules a network upgrade and hard fork, exchanges coordinate deposit and withdrawal suspensions similarly to how they handle L1 forks. NEAR Protocol, while technically a separate L1, has seen similar patterns, with Binance TH pausing NEAR withdrawals and deposits around a planned hard fork but leaving trading open. This convergence shows that, from an operational perspective, the distinction between L1 and L2 forks is narrowing: both require client upgrades, both can briefly disrupt deposits, and both depend on social consensus.

In the future, we can expect rollup ecosystems to see more explicit forks—perhaps when a rollup community disagrees over sequencer decentralization, MEV capture, or censorship policies. One branch might adopt more aggressive privacy features; another might align more tightly with Ethereum’s base‑layer policy choices. In such cases, ETH bridged into the rollup might be represented differently on each branch, leading to complex questions about canonical assets and redemption rights.

Security implications of app‑level forks

Forks at the protocol and application layers have distinct security implications. When a base chain hard forks, all applications on it are affected simultaneously. When a DeFi protocol or DEX forks, only users of that protocol are directly impacted, but the risks can propagate via composability: a bug in a forked lending market could cascade into liquidations across multiple protocols.

The Haveno‑derived XMR DEX exploit underscores this interconnectedness. A fork that altered or omitted strict state‑machine checks created an exploitable condition, allowing an attacker to steal around 7,000 XMR. This not only harmed users of the forked DEX; it also prompted scrutiny of Haveno itself and of other protocols that might have borrowed similar patterns. Security researchers and integrators must therefore track forks across layers, not just base chains. A fork that claims to “fix” a problem may itself introduce new ones if it is rushed or insufficiently reviewed.

On the flip side, forks like Zcash’s emergency Orchard soft fork show how protocol‑level interventions can contain vulnerabilities before they spread. By temporarily disabling a feature via soft fork and then re‑enabling it via hard fork with a corrected circuit, Zcash developers contained the blast radius. This pattern—restrictive soft fork plus corrective hard fork—could become a standard playbook for other privacy chains facing critical bugs in complex proving systems.

Forks, Ethereum, and the road to quantum resistance

Forks are not just about immediate upgrades; they are also central to long‑term strategic questions, such as how to prepare for quantum computers that might one day break existing cryptography. Ethereum’s research roadmap on post‑quantum security provides a nuanced view of how and when forks might be needed for this transition.

Ethereum’s fork-driven roadmap

As noted earlier, Ethereum delivers major changes via named hard forks like Fusaka, Glamsterdam, and Hegotá. These upgrades span both the consensus layer (Beacon Chain) and the execution layer (EVM), requiring coordinated client releases, devnets, and interop testing. Glamsterdam’s enshrined proposer‑builder separation (ePBS) is itself a kind of “fork inside a fork”: it redefines the division of labor in block production, potentially reducing out‑of‑protocol MEV markets and making the network more robust. Block‑level access lists, meanwhile, enable more efficient transaction execution, laying the groundwork for gas limit increases.

Looking ahead, Hegotá is expected to carry even more ambitious changes, including account abstraction features that will underpin Ethereum’s post‑quantum transition. One prominent proposal, EIP‑8141, aims to give accounts signature agility: the ability to change their signature scheme without requiring a protocol‑wide switch. Instead of forcing every account to abandon ECDSA simultaneously, Ethereum can allow individual users and contracts to adopt post‑quantum signatures as wallets and standards mature.

Ethereum’s official post‑quantum roadmap outlines a series of “structured fork milestones” stretching toward 2029, including a post‑quantum key registry, PQ signature verification precompiles, and PQ attestations for validators. These milestones will likely be delivered across multiple hard forks, not in a single “quantum hard fork.” This incremental approach spreads the engineering risk and allows the ecosystem to experiment with different signature schemes (such as lattice‑based or hash‑based signatures) without committing prematurely to a single choice.

Do we need a “quantum hard fork”?

The urgency of quantum‑resistant forks hinges on realistic threat models. In March 2026, Google Quantum AI published research estimating that breaking 256‑bit elliptic curve cryptography—the kind used for Ethereum account signatures—could require roughly 1,200 logical qubits. Previous estimates put that number much higher, but even 1,200 logical qubits is far beyond current hardware. Nonetheless, the research prompted institutions like Google to set internal deadlines for migrating to post‑quantum cryptography, with timelines around the end of this decade.

The U.S. National Institute of Standards and Technology (NIST) likewise anticipates deprecating ECDSA by around 2030 and disallowing it entirely by 2035. Ethereum’s documentation emphasizes that this is not an imminent threat: no quantum computer today can break Ethereum’s cryptography, and most researchers consider a realistic attack to be several years away at minimum. The goal, therefore, is preparation rather than panic: ensuring that when post‑quantum signatures are ready for production, Ethereum’s protocol and tooling can support them smoothly.

One strand of research suggests that a full protocol fork might not even be necessary for Ethereum’s first phase of post‑quantum protection. Ethereum researcher Nico has proposed an account‑level solution that can be deployed today without a hard fork, reportedly costing roughly USD 0.07 per account to set up, and has indicated that the design has completed an initial review. This approach leverages existing smart contract functionality and account abstraction patterns: users can move their funds into contract‑controlled accounts that verify post‑quantum signatures, without waiting for new precompiles or opcodes. Early experiments with schemes like SPHINCS+ have even demonstrated that verifying post‑quantum signatures can fit within current gas limits, on the order of hundreds of thousands of gas per verification, without a dedicated precompile.

Still, to make post‑quantum security a first‑class citizen, Ethereum will eventually need protocol‑level support: precompiles for efficient verification, changes to validator key management, and perhaps new rules for aggregating signatures in consensus. Those changes are likely to arrive via the same hard‑fork mechanism as other upgrades. The distinction is that Ethereum is trying to avoid one massive “quantum hard fork” that simultaneously changes everything; instead, it plans to layer PQ capabilities gradually, letting users opt in as needed.

Other ecosystems may take different paths. Some may indeed choose a “quantum hard fork” that rewrites key formats, invalidates old signature schemes, or even redistributes coins that are not migrated by a deadline. Charles Hoskinson’s comments about a potential “Bitcoin quantum hard fork” highlight how contentious such decisions could be: should old keys be forcibly moved, or should coins at risk of theft simply be considered lost? Each answer implies a different relationship between social governance and protocol rules—and each could spawn new forks if communities disagree.

How to navigate forks as a user, builder, or investor

For crypto users and professionals, the key challenge is not memorizing every fork’s details but understanding how forks affect assets, operational processes, and risk.

From a user perspective, the most immediate concern is whether a fork will create duplicate coins. Chain‑splitting hard forks like Ethereum/ETC or Bitcoin/BCH give holders assets on both sides of the split. In such cases, self‑custody of private keys is crucial: if your ETH or BTC is held on a centralized exchange at the time of the fork, the exchange’s policy determines whether you receive the forked coins. By contrast, non‑contentious hard forks and soft forks that serve as routine upgrades do not create new tradable assets; your balance continues smoothly on the canonical chain.

Exchanges’ maintenance announcements are a useful signal of when forks are coming. Binance’s support notices for Base and NEAR upgrades show the usual pattern: deposits and withdrawals are paused shortly before the activation time, while spot trading continues. After the hard fork completes and the network is stable, deposits and withdrawals resume. If a fork remains contentious or experiences technical issues, these pauses may last longer, but the exchange’s communication allows users to plan.

Validators, miners, and node operators face a different set of concerns. They must decide which client versions to run, how to coordinate upgrades across their infrastructure, and how to hedge exposure if a fork proves more contentious than expected. In Ravencoin’s BIP9 soft fork for an asset bug, for example, miners have a one‑year window to adopt new software and signal support. If the 70% threshold is reached, the new rules activate; if not, the proposal expires and must be reconsidered. In the interim, miners running old software risk mining blocks that could later be considered invalid, while miners running new software risk being on an effectively minority chain if the upgrade fails to gain traction.

For builders, forks are both an opportunity and a constraint. DeFi teams must ensure their contracts behave correctly across network upgrades, especially when gas costs, opcodes, or transaction ordering rules change. Ethereum’s Glamsterdam fork, with its move toward parallel execution and higher gas limits, could affect how batch auctions, liquidations, or arbitrage bots behave. Protocols built on rollups must also track both L2 and L1 forks, as changes in data‑availability pricing or precompile behavior can impact their economics. For projects that might themselves be forked—such as AMMs, lending systems, or launchpad‑style protocols—clear licensing and governance mechanisms can help manage expectations about what happens when a community or a rival team launches a derivative.

Finally, for long‑term investors, forks are a lens for evaluating governance robustness. Networks that handle forks in a transparent, well‑communicated way, with strong client diversity and independent security review, are more likely to survive crises and deliver upgrades safely. Networks that rely on opaque decision‑making or single‑client monocultures may appear nimble until a critical bug or contentious proposal forces a rushed fork. Tracking how ecosystems like Bitcoin, Ethereum, Polygon, and BNB respond to incidents—from the DAO hack to Zcash’s Orchard bug—provides valuable insight into their resilience.

Conclusion

Forks in crypto are often portrayed either as dramatic civil wars or as dry technical milestones, but in reality they are both the engines of innovation and the pressure valves of blockchain governance. Technically, forks are rule changes that create multiple potential paths forward for a chain or protocol; socially, they are moments when communities must decide which path to recognize as legitimate. The same mechanism that allowed Ethereum to reverse The DAO hack also enables planned upgrades like Glamsterdam and Hegotá, as well as the birth of entirely new currencies like Bitcoin Cash and eCash.

Understanding the distinctions between temporary forks, soft forks, and hard forks—and between non‑contentious upgrades and enduring chain splits—is crucial for anyone navigating today’s multi‑chain environment. Temporary forks arise naturally and are quickly resolved by longest‑chain rules. Soft forks tighten validation rules in backward‑compatible ways, but can obscure the fact that older nodes no longer fully validate the chain. Hard forks expand what is allowed or otherwise make incompatible changes, requiring explicit coordination and risking persistent splits when consensus fails. Real‑world case studies like Ethereum’s 2016 split, Zcash’s Orchard emergency, BNB’s Osaka/Mendel upgrade, and Polygon’s Zurich Hard Fork show how these abstractions play out in practice.

Looking ahead to challenges like post‑quantum security and native privacy transfers, forks will remain central tools for protocol designers. Ethereum’s approach—layering post‑quantum capabilities across multiple structured forks while enabling account‑level solutions that do not require immediate hard forks—illustrates a mature, incremental strategy. Other ecosystems may choose more radical paths, including “quantum hard forks” that rewrite key schemes or redistribute unmigrated coins. In each case, the details of how forks are designed, debated, and deployed will fundamentally shape user safety, asset value, and the evolution of crypto’s social contracts.

Outlook

Forks are becoming more frequent, not less, as crypto matures. Every major Ethereum upgrade, every L2 performance tweak, every BNB or Polygon hard fork, and every DeFi protocol clone adds another layer of branching to an already complex ecosystem. At the same time, the industry is developing more disciplined fork processes: multi‑client testing, formal activation mechanisms like BIP9, emergency soft‑fork playbooks, and clearer exchange coordination. This maturation should make forks less chaotic and more predictable for users, even as the stakes rise.

Over the next decade, quantum readiness and privacy will likely drive some of the most contentious fork debates. Whether networks choose gradual, opt‑in paths or sweeping protocol overhauls, forks will be the levers by which those choices are implemented. For investors, builders, and everyday users, keeping an eye on upcoming forks—and understanding their motivations and mechanics—will remain one of the most reliable ways to anticipate change in crypto’s evolving landscape.