Upgrade Mechanism

The process for proposing and ratifying upgrades, ranging from centralized to decentralized control.

• On-Chain Governance: Token holders vote directly on proposals (e.g., Cosmos, Tezos).
• Off-Chain Governance: Proposals are debated and signaled via forums/snapshot votes, with core developers implementing the consensus (e.g., Ethereum, Bitcoin).
• Multisig Councils: A designated group of keyholders authorizes upgrades (common in early-stage L2s).

The technical method for deploying new code to the network.

• Hard Fork: A permanent divergence from the previous chain; nodes must upgrade to follow new rules (e.g., Ethereum London, Bitcoin Taproot).
• Soft Fork: A backward-compatible rule tightening; non-upgraded nodes still see blocks as valid (e.g., Bitcoin SegWit).
• Social Fork: A community split where factions follow different rule sets after a contentious upgrade (e.g., Ethereum Classic).

Design patterns that allow smart contract logic to be changed while preserving state and address.

• Proxy Pattern: Uses a proxy contract that delegates calls to a separate, upgradeable logic contract. Users interact with the immutable proxy address.
• Diamond Pattern (EIP-2535): A modular proxy standard supporting multiple logic contracts (facets) for granular upgrades.
• Migration: Deploying a new contract and moving all state and users to it, often complex and costly.

Security features that enforce a mandatory waiting period between an upgrade's approval and its execution.

• Purpose: Provides a final review window for users and developers to react (e.g., exit funds, audit changes).
• Implementation: A smart contract or protocol parameter that queues an approved upgrade for a set duration (e.g., 48 hours) before it goes live.
• Example: Compound's Governor Bravo uses a timelock contract for all protocol changes.

How an upgrade handles existing on-chain data and user balances.

• Critical Consideration: A successful upgrade must not corrupt or lose the existing state (balances, contract storage).
• Proxy Patterns excel here by decoupling storage layout from logic.
• Storage Collisions are a major risk in upgradable contracts if new logic incorrectly accesses old storage slots.

Safety mechanisms to pause functionality or revert upgrades in case of critical bugs.

• Pause Functions: A privileged function that can halt key contract operations.
• Emergency Delay: A multi-signature council can override or delay a malicious upgrade.
• Proxy Admin: A dedicated address with the power to change the proxy's logic contract pointer, serving as a last-resort upgrade veto.

A hard fork is a permanent divergence from the previous version of a blockchain, creating a new chain that is incompatible with older nodes. Nodes must upgrade their software to continue validating new blocks.

• Creates a new chain: Results in a permanent split if not all nodes upgrade.
• Backwards incompatible: Old software cannot process new blocks.
• Examples: Ethereum's London Upgrade (EIP-1559), Bitcoin's SegWit activation.

A soft fork is a backwards-compatible upgrade where new rules are a subset of the old rules. Non-upgraded nodes can still validate new blocks, but they may not fully understand them.

• Backwards compatible: Old nodes accept new blocks as valid.
• Tightens rules: New rules are more restrictive (e.g., reducing block size).
• Examples: Bitcoin's Pay-to-Script-Hash (P2SH), SegWit as initially deployed.

A social consensus fork occurs when a community splits over a contentious protocol change, leading to two competing chains. The "legitimate" chain is determined by community support, not just code.

• Driven by governance: Resolution happens off-chain through miner, developer, and user consensus.
• Results in a chain split: Creates two separate assets (e.g., ETH/ETC, BTC/BCH).
• Defines canonical chain: The chain with the most economic activity is typically considered the successor.

A governance-driven upgrade uses on-chain voting mechanisms to propose and enact protocol changes. Token holders or delegated representatives vote on proposals that are automatically executed upon approval.

• On-chain voting: Proposals and votes are recorded on the blockchain.
• Automated execution: Code changes are deployed automatically after a successful vote.
• Examples: Compound's and Uniswap's governance systems, which control treasury and protocol parameters.

A bridge and layer upgrade involves deploying improvements on a separate execution layer (L2) or via a bridging contract, minimizing risk to the base layer (L1). The core protocol remains unchanged while new functionality is added externally.

• L1 remains stable: Core blockchain rules are not altered.
• Modular innovation: New features are built on top via rollups, sidechains, or state channels.
• Examples: Upgrading an Optimistic Rollup's fraud proof system or a cross-chain bridge's security model.

A timelock and multisig upgrade uses a smart contract with a delay (timelock) and requires multiple authorized signatures (multisig) to execute changes. This creates a security buffer and ensures changes are transparent and collaborative.

• Introduces a delay: The community has time to review code before it goes live.
• Requires multiple signers: Prevents unilateral action by any single party.
• Common in DeFi: Used by protocols like MakerDAO and Aave to upgrade core contracts securely.

The most common upgrade pattern uses a proxy contract that delegates calls to a separate logic contract. A critical risk is storage collision, where the new logic contract's variable layout does not perfectly match the proxy's storage slots, leading to catastrophic data corruption. Meticulous storage layout management and using established patterns like EIP-1967 are essential mitigations.

Upgrade mechanisms typically rely on an admin address or multisig with the authority to change the logic contract. This creates a central point of failure:

• Malicious Admin: A compromised key can upgrade the contract to steal funds or change rules.
• Governance Delay: While DAO-based upgrades are more decentralized, they can be slow to respond to critical bugs.
• Rug Pull Vector: Malicious developers can retain upgrade keys to later drain the protocol.

A timelock is a critical security control that enforces a mandatory delay between when an upgrade is proposed and when it is executed. This allows users to:

• Audit the new code before it goes live.
• Exit the protocol if they disagree with the changes.
• Detect malicious proposals from a compromised admin key. Without a timelock, upgrades are instant and irreversible, offering no protection.

Upgradable contracts cannot use standard constructors because the proxy, not the logic contract, handles deployment. Instead, they use initializer functions. Key risks include:

• Re-initialization Attacks: If not properly guarded, an attacker can call the initializer to reset contract state.
• Function Selector Clashes: Adding new functions in an upgrade can accidentally override existing ones if their 4-byte selectors collide, breaking core functionality.

Upgradability inherently breaks the "code is law" paradigm, as the rules can change. This requires significant transparency to maintain user trust. Best practices include:

• Publicly announcing all upgrade proposals with detailed changelogs.
• Providing opt-out mechanisms or migration paths for users.
• Undergoing rigorous audits for every new implementation. The lack of these can lead to loss of user confidence and protocol abandonment.

The ultimate risk mitigation is immutability—deploying a final, unchangeable contract. While this eliminates upgrade-related risks, it introduces others:

• Permanent Bugs: A critical vulnerability in an immutable contract is unfixable, often leading to permanent fund loss.
• Inflexibility: The protocol cannot adapt to new innovations or standards. The choice between upgradability and immutability is a fundamental security and design decision.

Polkadot's key innovation is forkless runtime upgrades. The chain's logic (the runtime) is stored on-chain and can be updated via a referendum voted on by token holders. Once approved, the upgrade is enacted automatically at a specific block. This avoids the need for a coordinated hard fork and allows for seamless evolution of parachains. The Substrate framework provides the underlying upgrade machinery.

Solana uses a feature activation system to manage upgrades. New features are deployed into the validator software but remain dormant behind a feature gate. Once a supermajority of the stake has upgraded to a version that includes the feature, it is automatically activated on-chain at a specific slot. This allows for smoother transitions and backward compatibility, as seen with the rollout of the QUIC protocol and fee markets.

Arbitrum's upgrade path evolved from centralized control to decentralized governance. Initially, upgrades on Arbitrum One were executed by a multisig wallet controlled by Offchain Labs. With the launch of the Arbitrum DAO, upgrade authority was transferred to token holders. Now, upgrades are proposed and voted on via Arbitrum Improvement Proposals (AIPs), with execution managed by a Security Council, illustrating a common L2 progression.