An opt-in upgrade is a backward-compatible modification to a blockchain's protocol that is not enforced by network consensus, meaning existing nodes can continue operating on the old rules without disruption. This contrasts with a hard fork, which creates a permanent divergence and requires all nodes to upgrade to remain on the canonical chain. Opt-in upgrades are typically implemented via soft forks or through modular components where adoption is elective, such as new transaction types or virtual machine versions that only activated nodes can process. This model prioritizes user agency and minimizes coordination failure risks.
LABS
Glossary
Opt-In Upgrade
An opt-in upgrade is a protocol change where participants must explicitly signal readiness or take action to adopt new rules, contrasting with automatic upgrades.
Chainscore © 2026
definition
BLOCKCHAIN GOVERNANCE
What is an Opt-In Upgrade?
An opt-in upgrade is a backward-compatible protocol change that requires explicit action from node operators or users to adopt, unlike a mandatory hard fork.
The primary mechanism for an opt-in upgrade often involves a flag day or activation mechanism where nodes signal readiness. A canonical example is Bitcoin's Segregated Witness (SegWit) upgrade, which was deployed as a soft fork. Old nodes could still validate blocks and transactions but could not create the new SegWit transaction types; only upgraded nodes could fully participate in the new features. Similarly, Ethereum's Shanghai Upgrade included an optional EIP-4895 for beacon chain withdrawals, which was only relevant to validators who chose to exit the staking contract.
Key advantages of the opt-in model include reduced network fragmentation, as it avoids chain splits, and lower upgrade coordination costs. It allows for gradual, organic adoption where economic actors can assess new features before committing. However, it can lead to slow feature adoption and create complexity if multiple protocol versions operate simultaneously. This approach is fundamental to modular blockchain architectures and layer-2 networks, where users opt into specific execution environments or rule sets without affecting the base layer's stability.
how-it-works
BLOCKCHAIN GOVERNANCE
How Does an Opt-In Upgrade Work?
An explanation of the mechanism that allows blockchain participants to voluntarily adopt new protocol rules.
An opt-in upgrade is a backward-compatible protocol change where network participants—such as node operators, validators, or users—must explicitly choose to adopt the new rules. This contrasts with a hard fork, which is a mandatory, network-wide upgrade. The process begins with the proposal and implementation of new features or improvements into the node software. This new version is then made available, but it does not automatically activate; instead, it contains logic that triggers the new rules only when a specific condition, like a predetermined block height or a sufficient percentage of network participants signaling readiness, is met.
The core mechanism relies on signaling, where participants running the new software broadcast their support for the activation. For example, in a Proof-of-Work chain, miners might signal by including a specific bit in their mined blocks. Once a supermajority threshold (e.g., 90% of blocks) is reached over a defined period, the upgrade is locked in and activates at a future block. Until activation, the network continues to operate under the old consensus rules, and nodes that do not upgrade remain fully compatible and operational. This creates a grace period for coordination and reduces the risk of a chain split.
A key advantage of this model is sovereignty and reduced coordination overhead. Node operators and ecosystem participants can upgrade at their own pace after testing the new software, without the immediate pressure of a hard fork deadline. It also allows for a cleaner user-activated soft fork (UASF) scenario, where economic nodes (exchanges, wallets) can enforce an upgrade by rejecting blocks that do not signal for it. However, successful execution requires broad community consensus and clear communication to ensure enough participants signal in time, avoiding a stalled upgrade or a contentious split where a minority continues the old chain.
key-features
MECHANISM
Key Features of Opt-In Upgrades
Opt-in upgrades are a governance mechanism that allows individual users to choose whether to adopt a new protocol version, contrasting with mandatory, network-wide hard forks.
01
User Sovereignty
The core principle is user choice. Each token holder or node operator independently decides to migrate their assets or client to the new rules. This prevents the network split risk inherent in contentious hard forks, as both old and new versions can coexist. Users are not forced into upgrades they disagree with, preserving decentralized governance.
02
Backwards Compatibility
The new, upgraded protocol is designed to be backwards compatible with the existing chain state. This means:
- The old client software remains functional.
- Assets on the old chain (e.g., legacy tokens) are still valid.
- State separation is maintained, preventing conflicts between opted-in and non-opted-in users. It's a technical design that enables a smooth, non-disruptive transition period.
03
Dual-State Operation
During the transition, the network operates with two parallel states: the legacy state and the upgraded state. A bridge or migration contract is typically deployed to facilitate the one-way, permissionless movement of assets from the old state to the new. This creates a clear, auditable path for adoption without invalidating the original chain.
04
Contrast with Hard Forks
This model fundamentally differs from a hard fork.
- Hard Fork: Mandatory, breaking change requiring unanimous node upgrade; creates a single new chain.
- Opt-In Upgrade: Optional, non-breaking change; creates a new state layer or sidechain linked to the original. It is a softer consensus change that prioritizes continuity and minimizes coordination overhead.
05
Implementation Examples
Real-world implementations include:
- EIP-1559 (Fee market change): A pseudo-opt-in upgrade where users could choose new transaction types.
- Uniswap v3 Migration: A contract-level opt-in where liquidity providers manually moved funds to a new, more efficient contract.
- Starknet's Quantum Leap: An upgrade where users opted in by updating their node software, with the old version remaining valid for a time.
06
Governance & Coordination
While reducing forced coordination, opt-in upgrades still require significant social consensus and clear communication. Successful execution depends on:
- Transparent governance proposals and signaling.
- Robust developer tooling and documentation for the migration path.
- Economic incentives (e.g., yield boosts) to encourage timely adoption by a critical mass of users.
UPGRADE MECHANISM COMPARISON
Opt-In Upgrade vs. Mandatory Upgrade
A comparison of the key characteristics, governance, and impact of two primary blockchain protocol upgrade models.
| Feature | Opt-In Upgrade (Soft Fork) | Mandatory Upgrade (Hard Fork) |
|---|---|---|
Node Operator Action | Optional; nodes can choose to adopt the new rules. | Mandatory; all nodes must upgrade to the new client software. |
Backward Compatibility | ||
Chain Split Risk | Low; non-upgraded nodes remain on the canonical chain. | High; non-upgraded nodes are forked onto a separate, incompatible chain. |
Governance Model | Coordinated activation (e.g., BIP-9, EIPs) requiring supermajority signaling. | Binary decision; the upgrade is deployed at a specific block height. |
User Impact | Minimal; users are not forced to take action unless they run a node. | High; all users must ensure their wallets and services support the new chain. |
Typical Use Case | Adding new features, optimizations, or tightening rules (e.g., SegWit, London Upgrade). | Introducing breaking changes or fundamental new consensus rules (e.g., Ethereum Merge, The DAO fork). |
Activation Threshold | ~90-95% of hashrate or stake | |
Post-Upgrade Network State | Single, unified chain. | Potential for two persistent chains if a significant minority rejects the upgrade. |
examples
OPT-IN UPGRADE
Historical & Protocol Examples
Opt-in upgrades are a critical governance mechanism, allowing networks to evolve without forcing changes on all participants. These examples illustrate how major protocols have implemented this concept.
04
The DAO Fork & Ethereum Classic
The response to The DAO hack (2016) is a seminal example of an opt-in upgrade creating a chain split. The Ethereum Foundation proposed a contentious hard fork to reverse the hack.
- Opting In: Nodes that updated client software followed the new fork (Ethereum, ETH).
- Opting Out: Nodes that rejected the upgrade continued on the original chain (Ethereum Classic, ETC). This event permanently defined code is law versus social consensus philosophies in blockchain governance.
06
Contrast: Opt-Out (Activation) Mechanisms
Not all upgrades are purely opt-in. Key opt-out mechanisms provide contrast:
- User-Activated Soft Fork (UASF): In Bitcoin, BIP 148 was a user-enforced soft fork where nodes signaled readiness, creating economic pressure for miners to follow.
- Mandatory Upgrades: Some security patches or critical bug fixes are effectively mandatory; not upgrading risks funds or network exclusion, making the 'opt-in' choice a necessity for participation.
security-considerations
OPT-IN UPGRADE
Security & Network Considerations
An opt-in upgrade is a blockchain protocol change where node operators must manually activate the new rules, creating a temporary state of network divergence.
01
Mechanism of Activation
An opt-in upgrade is activated via a user-activated soft fork (UASF) or flag day. Node operators signal readiness by setting a specific flag or upgrading their client software by a predetermined block height. Unlike a mandatory hard fork, nodes that do not upgrade continue operating under the old rules, creating a chain split until a supermajority enforces the new chain.
02
Key Security Benefit
The primary security advantage is backward compatibility and reduced coercion risk. It prevents a situation where a minority of users are forcibly disconnected from the network by a contentious change. This model aligns with the principle of consensus rather than flat, as adoption is voluntary and demonstrates organic network support.
03
Coordination Challenge
Success requires exceptional social coordination and clear communication. Risks include:
- Prolonged chain split: If significant economic activity remains on the old chain.
- Replay attacks: Transactions could be valid on both chains, requiring protection.
- Miners' dilemma: Miners must choose which chain to support, potentially splitting hash power. The 2017 Bitcoin SegWit activation via BIP 91/BIP 148 is a canonical example of this challenge.
04
Contrast with Hard Fork
This differs fundamentally from a hard fork (a backward-incompatible upgrade).
- Hard Fork: All nodes must upgrade to follow the new chain; the old chain is abandoned.
- Opt-In Upgrade: Nodes may upgrade; both old and new chains can coexist temporarily. Opt-in upgrades are often used for soft forks, where new rules are a subset of old rules, allowing non-upgraded nodes to still validate blocks.
05
Economic Finality & Warnings
During the activation period, economic finality is uncertain. Wallets and exchanges typically display prominent warnings (e.g., "Unsafe Chain") for the non-upgraded chain. Services freeze deposits/withdrawals until a dominant chain emerges. The upgrade is considered successful when the new chain attracts the overwhelming majority of hash rate and economic activity, causing the old chain to become economically non-viable.
06
Related Concepts
- Soft Fork: A tightening of consensus rules, often deployed via opt-in mechanisms.
- Hard Fork: A broadening of rules, requiring a mandatory upgrade.
- Chain Split: The temporary or permanent divergence of a blockchain into two.
- BIP-9: A version bits soft fork deployment mechanism used for signaling.
- User-Activated Soft Fork (UASF): A specific type of opt-in upgrade driven by full nodes, not miners.
role-in-modular-stack
OPT-IN UPGRADE
Role in the Modular Blockchain Stack
An opt-in upgrade is a mechanism within a modular blockchain stack that allows individual components, such as a rollup or a sovereign chain, to independently adopt new features or protocol changes without requiring a coordinated hard fork of the entire network.
In a modular blockchain architecture, sovereignty and upgradeability are decentralized across different layers. An opt-in upgrade empowers a specific chain or execution layer (like a rollup) to implement changes—such as a new virtual machine, precompiles, or fee mechanisms—by its own governance or validator set. This is in stark contrast to a monolithic chain, where any protocol change necessitates a system-wide hard fork, requiring consensus from the entire network's node operators and often leading to contentious splits.
The mechanism is foundational for sovereign rollups and app-specific chains. For example, a rollup built on a data availability layer like Celestia can deploy an upgrade to its execution logic by having its sequencers adopt new software and posting the upgraded chain's state roots and proofs to the base layer. Users and validators who wish to follow the new chain simply run the updated client software, creating a clean fork choice rule based on the canonical data published on the base layer.
This model separates social consensus from technical consensus. The underlying data availability and settlement layers provide the technical bedrock of security and ordering, but the decision to adopt a new set of rules is a social contract among the users and builders of the opting-in chain. It enables rapid innovation and experimentation at the execution layer without imposing risk or change on unrelated applications and chains sharing the same modular infrastructure.
OPT-IN UPGRADES
Common Misconceptions
Clarifying frequent misunderstandings about how smart contract upgrades work in practice, focusing on the mechanics, security implications, and governance models of opt-in upgrade patterns.
No, an opt-in upgrade is a design pattern, while a proxy contract is a specific implementation mechanism. An opt-in upgrade describes a system where users must explicitly agree to migrate to a new contract version, often by calling a function to update their token balances or state. This pattern can be implemented using various technical approaches, including:
- Direct migration contracts that hold new tokens until claimed.
- Wrapper contracts that delegate to a new logic address.
- Proxy patterns (like Transparent or UUPS) where the proxy delegatecalls to a logic contract, but the upgrade is only effective for users who "opt-in" by interacting with a new function. The key distinction is user consent; a standard proxy upgrade affects all users immediately, whereas an opt-in pattern requires individual action.
OPT-IN UPGRADE
Frequently Asked Questions (FAQ)
An opt-in upgrade is a protocol change that requires explicit action from network participants to adopt, ensuring backward compatibility and user choice. This section addresses common questions about its mechanics and implications.
An opt-in upgrade is a backward-compatible protocol change where users must explicitly signal their adoption, often by running new client software, while the old protocol rules remain functional. This contrasts with a mandatory hard fork. The process typically involves:
- Protocol developers finalize and release new client software.
- Node operators and validators choose to install the new software, activating the new features on their nodes.
- Users interact with the upgraded protocol by sending transactions to nodes that support it.
- Network bifurcation can occur temporarily, creating two parallel chains until adoption reaches consensus. A canonical example is Ethereum's London upgrade, which introduced EIP-1559; nodes that did not upgrade continued to process transactions under the old fee market rules, but were eventually incentivized to upgrade for security and efficiency.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall