Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
LABS
Glossary

Upgrade Proposal

An upgrade proposal is a formal governance mechanism for modifying a decentralized protocol's code, parameters, or smart contract addresses.
Chainscore © 2026
definition
BLOCKCHAIN GOVERNANCE

What is an Upgrade Proposal?

A formal mechanism for modifying the rules, features, or parameters of a decentralized network.

An upgrade proposal is a formal, on-chain or off-chain submission that outlines a specific change to a blockchain's protocol, such as its consensus rules, virtual machine, or economic parameters. It is the primary governance instrument in decentralized networks, initiating a process where token holders or designated validators vote to accept or reject the proposed modifications. These proposals are essential for network evolution, enabling bug fixes, performance enhancements like EIP-1559, and the activation of major forks such as Ethereum's London or Shanghai upgrades.

The lifecycle of a proposal typically follows a structured path: discussion in community forums, drafting of formal specifications (e.g., an Ethereum Improvement Proposal or EIP), submission to the governance module, a voting period, and finally execution if approved. On networks like Cosmos or Tezos, proposals are native on-chain operations, while others, like Bitcoin, rely more on off-chain Bitcoin Improvement Proposal (BIP) coordination among developers and miners. The voting power is usually weighted by a user's stake in the network's native token.

Key technical considerations include backward compatibility and activation mechanisms. A hard fork proposal requires all nodes to upgrade to remain on the canonical chain, while a soft fork maintains backward compatibility. Proposals must specify an activation block height or timestamp. Failure to reach consensus can lead to network splits, as historically seen with Ethereum and Ethereum Classic. Modern frameworks often include timelocks and multisig execution to add security and deliberation time post-approval.

For developers and node operators, monitoring upgrade proposals is critical. An approved proposal mandates that all participating nodes install new client software before the activation deadline. Proposals can introduce new precompiled contracts, adjust gas costs, or change staking rewards. Analysts track proposal sentiment and voting metrics as key indicators of a protocol's decentralization and governance health, assessing the alignment between token holders and core developers.

how-it-works
GOVERNANCE MECHANISM

How an Upgrade Proposal Works

An upgrade proposal is the formal process by which a decentralized network's stakeholders vote to implement changes to its core protocol, smart contracts, or economic parameters.

An upgrade proposal is a formal, on-chain governance mechanism that initiates a vote to modify a blockchain's protocol. It is the primary method for enacting changes to a network's consensus rules, virtual machine, tokenomics, or other fundamental parameters. Proposals are typically submitted by a community member or core development team and contain a detailed specification of the proposed change, such as an Ethereum Improvement Proposal (EIP) or a Cosmos SDK software upgrade. The proposal is then broadcast to the network, where it enters a formal discussion and voting period governed by the protocol's native governance token.

The voting process is executed via smart contracts, with token holders casting votes proportional to their stake or token balance. Different networks employ various voting models, including simple majority, quadratic voting, or approval voting. A quorum—a minimum threshold of total voting power—must be met for the result to be valid. If the proposal passes with the required supermajority, it is scheduled for execution. For upgrades that modify core consensus logic (a hard fork), node operators must manually adopt the new client software. For changes to application-layer smart contracts, execution can be automated via a timelock contract, which enforces a delay between approval and implementation to allow users to react.

A canonical example is a network upgrade like Ethereum's London hard fork, which was enacted via EIP-1559. The proposal went through extensive off-chain discussion before a formal governance vote by token holders. Upon passing, a specific block height was set for activation, requiring all node operators to upgrade their clients to remain on the canonical chain. This process contrasts with social consensus-driven upgrades in networks like Bitcoin, where coordination is largely off-chain. The integrity of the process relies on transparent communication, robust tooling for submission and voting, and clear execution pathways to minimize network disruption or contentious splits.

key-features
BLOCKCHAIN GOVERNANCE

Key Features of an Upgrade Proposal

A formal upgrade proposal is a structured mechanism for modifying a blockchain's protocol. Its core features ensure changes are transparent, secure, and reflect community consensus.

01

Technical Specification

The formal document detailing the proposed changes to the protocol's code. It includes:

  • EIP (Ethereum Improvement Proposal) or BIP (Bitcoin Improvement Proposal) numbers for standardized tracking.
  • A clear problem statement and technical rationale.
  • The exact code changes, often via a pull request to the core repository.
  • Implementation details, including backward compatibility and potential migration paths.
02

Governance Process

The structured pathway for community review and approval. This typically involves:

  • Forum Discussion: Initial debate on platforms like Ethereum's Fellowship of Ethereum Magicians or research forums.
  • On-Chain Voting: Formal signaling using the network's native governance token (e.g., UNI for Uniswap, AAVE for Aave).
  • Quorum & Thresholds: Minimum participation and required majority (e.g., 4% quorum, 50% majority) for the vote to be binding.
  • Timelock: A mandatory delay between vote approval and execution, allowing users to react.
03

Activation Mechanism

The method by which the new code is deployed and activated across the network. Common mechanisms include:

  • Hard Fork: A backward-incompatible change requiring all node operators to upgrade their software (e.g., Ethereum's London upgrade).
  • Soft Fork: A backward-compatible change where non-upgraded nodes still follow the new rules.
  • Activation Height/Block: A predetermined block number at which the new rules become active.
  • Flag Day Activation: Activation occurs when a certain percentage of nodes signal readiness.
04

Risk Assessment & Testing

The critical evaluation of potential impacts before mainnet deployment. This involves:

  • Audits: Formal security reviews by independent firms to identify vulnerabilities.
  • Testnet Deployment: Running the upgrade on a replica network (e.g., Goerli, Sepolia) to simulate behavior.
  • Economic & Security Analysis: Modeling impacts on staking rewards, gas fees, and slashing conditions.
  • Bug Bounties: Incentive programs to crowdsource vulnerability discovery before launch.
GOVERNANCE MECHANISMS

Types of Upgrade Proposals

A comparison of common blockchain upgrade proposal types, categorized by their governance mechanism and execution method.

Proposal TypeGovernance ModelExecution MethodNetwork ImpactExample Protocols

Hard Fork

Node Operator Adoption

Chain Split

High (Requires consensus split)

Bitcoin, Ethereum (pre-PoS)

Soft Fork

Miner/Supermajority Adoption

Backwards-Compatible Rule Tightening

Medium (Non-upgraded nodes follow new chain)

Bitcoin SegWit

On-Chain Governance

Token Holder Vote

Automated via Protocol

Low (Execution is protocol-enforced)

Tezos, Cosmos

Social Consensus / EIP

Developer & Community Consensus

Client Implementation

High (Relies on coordinated client upgrades)

Ethereum (Post-Merge)

Parameter Change Proposal

Governance Module Vote

Automated via Module

Low (Updates specific protocol parameters)

MakerDAO, Compound

Emergency Shutdown

Governance Module / Multi-sig

Protocol Halt

Critical (Pauses system operations)

MakerDAO, Aave

examples
UPGRADE PROPOSAL

Examples in Oracle Networks

An upgrade proposal is a formal, on-chain governance mechanism for modifying a decentralized oracle network's core protocol, such as its data sourcing logic, security parameters, or economic model.

06

The Governance Process

A typical upgrade proposal follows a structured on-chain governance process:

  1. Temperature Check: Informal signaling to gauge community sentiment.
  2. Formal Proposal: Code changes and specifications are submitted on-chain.
  3. Voting Period: Token holders vote to approve or reject (e.g., using snapshot or native governance).
  4. Timelock & Execution: If passed, changes are queued in a timelock contract for review before automatic execution, providing a final safety check.
technical-details
UPGRADE PROPOSAL

Technical Implementation Details

A structured document outlining the technical specifications, rationale, and execution plan for modifying a blockchain's protocol or smart contract system.

An upgrade proposal is a formal, on-chain or off-chain document that details the technical changes required for a protocol improvement, such as a hard fork, soft fork, or smart contract migration. It serves as the definitive blueprint for developers and the primary reference for community governance, specifying the block height or timestamp for activation, the new consensus rules, and any required state transitions. For networks like Ethereum, this is often an Ethereum Improvement Proposal (EIP), while Cosmos uses a Governance Proposal module to enact changes.

The core components of a technical proposal include the motivation explaining the problem or enhancement, the specification detailing the new code and data structures, and the rationale justifying the chosen approach over alternatives. It must also address backward compatibility, defining whether the change is breaking (hard fork) or optional (soft fork), and outline the testing and audit procedures, including deployment on testnets. Critical for security, the proposal includes a risk assessment covering potential attack vectors and network instability.

Execution involves a multi-phase process: after community discussion and reference implementation, the proposal is formalized and submitted for on-chain governance. Token holders or validators then vote, with approval requiring a supermajority of stake or votes. Upon passing, node operators must upgrade their client software before the activation deadline. A failed upgrade, such as Ethereum's DAO fork, or a contentious hard fork, like Bitcoin Cash, highlights the critical role of clear technical documentation and broad consensus in maintaining network integrity.

security-considerations
UPGRADE PROPOSAL

Security Considerations & Risks

Blockchain upgrade proposals, while essential for protocol evolution, introduce significant security risks that must be carefully managed. These risks center on governance, implementation, and network consensus.

01

Governance Attack Vectors

The process of proposing and voting on upgrades is vulnerable to manipulation. Key threats include:

  • Vote buying and bribery: Token holders may be incentivized to vote against the network's long-term health.
  • Whale dominance: Concentrated token ownership can lead to centralized decision-making.
  • Proposal spam: Malicious actors can flood governance with proposals to create fatigue or hide a harmful upgrade. These attacks can result in the approval of upgrades that degrade security, introduce backdoors, or enable theft.
02

Implementation & Code Risk

Even a well-intentioned upgrade can contain critical bugs. The primary risks are:

  • Smart contract vulnerabilities: New or upgraded contracts may have reentrancy, logic errors, or access control flaws.
  • Consensus bugs: Changes to core protocol rules (e.g., Ethereum's EIPs) can inadvertently cause chain splits or consensus failure.
  • Upgrade mechanism flaws: The code that executes the upgrade itself (like a proxy's upgradeTo function) can be a single point of failure. Thorough audits, formal verification, and testnet deployments are critical mitigations.
03

Chain Split & Replay Attacks

Contentious upgrades can cause a permanent chain split, where nodes disagree on the new rules, creating two competing blockchains (e.g., Ethereum and Ethereum Classic). This introduces immediate risks:

  • Replay attacks: A transaction valid on both chains can be maliciously "replayed" from one to the other, potentially draining funds.
  • Economic instability: The split creates uncertainty, often crashing the value of assets on both chains.
  • Infrastructure fragmentation: Wallets, exchanges, and oracles must choose a chain, breaking composability.
04

Validator/Node Coordination Failure

A successful upgrade requires near-synchronous adoption by network validators or miners. Failure risks include:

  • Non-upgraded nodes: Nodes running old software will reject new blocks, causing them to fork off onto an incompatible chain.
  • Slashing conditions: In Proof-of-Stake systems, validators may be slashed for equivocating if they are confused about the canonical chain.
  • Timing attacks: Malicious actors can exploit the transition period when the network is in a temporarily weakened, non-uniform state.
05

Client Diversity Risk

Networks with multiple independent software clients (e.g., Geth, Besu, Nethermind for Ethereum) face unique upgrade risks:

  • Client-specific bugs: An upgrade may expose a critical bug in one client, causing nodes using it to fail. If that client has a supermajority (>66%), it can halt the network.
  • Inconsistent implementation: Different client teams may interpret the upgrade specification differently, leading to consensus failure. This risk underscores the importance of maintaining healthy client diversity and coordinated testing.
06

Time-Lock & Escape Hatches

To mitigate upgrade risks, protocols implement safety mechanisms:

  • Timelocks: A mandatory delay between a proposal's approval and its execution, allowing users to exit or scrutinize the change.
  • Multisig or DAO-controlled upgrades: Upgrade authority is distributed among a council or decentralized autonomous organization.
  • Escape hatches / Guardians: Emergency pause functions or upgrade veto power held by a trusted, but limited, entity to stop catastrophic bugs. These features create a crucial safety buffer but must be designed to avoid centralization.
UPGRADE PROPOSAL

Frequently Asked Questions (FAQ)

Essential questions and answers about blockchain upgrade proposals, the formal mechanisms for evolving decentralized networks.

A blockchain upgrade proposal is a formal, structured suggestion to modify the protocol rules, client software, or economic parameters of a decentralized network. It functions as the primary governance mechanism for implementing changes, ranging from minor bug fixes to major consensus upgrades (hard forks). The process typically involves submitting a detailed specification (e.g., an Ethereum Improvement Proposal - EIP) for community discussion, technical review, and finally, on-chain signaling or voting by token holders or validators to reach consensus on adoption. Successful proposals are then coded into the network's node software and activated at a predetermined block height.

ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team