A Protocol Upgrade Proposal (PUP) is the formal mechanism for changing the OP Stack specification. Once approved, a PUP does not merely suggest a change—it creates a mandatory upgrade requirement for OP Mainnet and, under the Law of Chains, for all chains that have opted into Superchain governance. The process begins with a technical specification, moves through Token House approval, and is subject to a Citizens' House veto before the Security Council executes the onchain upgrade transaction. Chain operators and infrastructure teams must track this pipeline because the activation delay is finite and non-negotiable.

Protocol Upgrade Proposal Process
How OP Stack Protocol Upgrades Become Mandatory
The governance path that turns an OP Stack specification change into a binding, time-locked requirement for all Superchain participants.
The mandatory nature of a PUP is enforced by the ProtocolVersions contract, which records the current recommended and required versions. After the Security Council initiates an upgrade, a time-locked activation delay begins. Once this delay expires, the new protocol version becomes required, and any node running an older version will stop syncing at the activation block. This means exchanges, RPC providers, indexers, and bridge operators must complete their op-geth and op-node upgrades before the deadline or face an effective network halt. The delay is designed to give operators time to prepare, but it also creates a hard coordination point across the entire Superchain.
For teams operating OP Stack chains, the impact extends beyond a single client update. A PUP can alter derivation rules, change precompile behavior, modify gas or fee parameters, or introduce new cross-chain messaging semantics. These changes can break dependent systems such as wallets, bridges, or monitoring tools that rely on specific execution-layer behavior. Chainscore Labs helps operators and builders navigate this process with upgrade readiness reviews that map the exact technical changes in a PUP to the systems they affect, ensuring that integration code, monitoring alerts, and operational runbooks are updated before the activation deadline.
PUP Lifecycle at a Glance
The end-to-end governance path for a Protocol Upgrade Proposal, highlighting the mandatory stages, actors, and operational checkpoints that determine when and how an upgrade reaches mainnet.
| Phase | What happens | Key actors | Operational action |
|---|---|---|---|
Specification & Proposal Drafting | A technical specification is authored and a PUP is drafted on the Governance Forum, defining the upgrade scope and onchain execution payload. | Core developers, protocol architects, proposal authors | Review the specification for compatibility with dependent systems and integration points. |
Token House Voting | The proposal is submitted to a Token House vote. Approval requires a quorum and a majority threshold as defined by the Operating Manual. | OP token delegates, governance tooling providers | Delegates must evaluate the technical and economic impact; tooling providers should ensure correct vote display. |
Citizens' House Veto Period | After Token House approval, a veto period begins where the Citizens' House can block the proposal if it contravenes the collective's values. | Citizens' House members, governance monitors | Monitor for a veto event; a veto halts the process and returns the proposal to the community for revision. |
Security Council Review & Activation Delay | The Security Council reviews the approved proposal and initiates a mandatory activation delay to allow node operators to prepare. | Security Council members, node operators, chain operators | Begin upgrade readiness preparations immediately. Verify the delay duration against the canonical governance contract. |
Protocol Upgrade Activation | The upgrade is executed onchain at the end of the delay period. The new code becomes canonical for the network. | Node operators, exchanges, infrastructure providers | Update op-node and op-geth clients to the required release before the activation timestamp. Monitor post-upgrade network health. |
Post-Upgrade Monitoring | The network is monitored for chain halts, derivation failures, or unexpected state transitions in the hours and days following activation. | Validators, data teams, security monitors | Run integration tests, verify RPC and indexing service health, and report anomalies to the core development team. |
Proposal Flow: From Specification to Activation
The end-to-end governance path for OP Stack protocol upgrades, from technical specification to mandatory activation across the Superchain.
A protocol upgrade for Optimism and the OP Stack begins as a technical specification, often a design document or pull request against the op-stack repository, that defines a change to the execution client, derivation pipeline, or fault proof system. This specification is the source of truth for what the upgrade changes at the protocol level. It must be precise enough for client implementers, chain operators, and security auditors to understand the new behavior, any breaking changes to state transition, and the required software versions. The specification phase is where the scope of a Superchain Upgrade Proposal (SUP) is set, and it directly determines the integration work required by every OP Stack chain that intends to remain part of the Superchain.
Once a specification is stable, it enters the Optimism Collective governance process as a Protocol Upgrade Proposal (PUP). The Token House votes on whether to approve the upgrade. If approved, the proposal moves to the Security Council, which has the authority to activate a built-in delay or to veto the upgrade if a critical issue is discovered. This is not a ceremonial step; the Security Council's multisig is the practical control point for the upgrade transaction on OP Mainnet. For other OP Stack chains, the governance path varies: chains operating under the Law of Chains are expected to execute the upgrade to maintain Superchain compatibility, while independent chains must decide whether to adopt the change. The activation is not simultaneous—OP Mainnet typically upgrades first, followed by a window for other chain operators to prepare and execute.
For node operators, exchanges, and infrastructure teams, the period between Token House approval and the activation deadline is the critical readiness window. Teams must upgrade op-geth and op-node to the required versions, validate that their monitoring and alerting logic aligns with any new protocol behavior, and coordinate with partners on testnet verification. A missed upgrade can result in a chain halt or a divergence from the canonical Superchain state. Chainscore Labs provides upgrade readiness reviews that map the specification to your operational stack, identify breaking changes in derivation or execution, and validate that your integration and monitoring systems are prepared for the activation. For chain operators evaluating whether to adopt a PUP, we offer impact assessments that model the operational and economic consequences of the change.
Who Is Affected by a PUP
Chain Operators
Chain operators running OP Stack chains are the primary affected party. A PUP mandates a protocol version bump that must be applied before the activation deadline to avoid chain halts or derivation failures.
Immediate actions:
- Monitor the
op-nodeandop-gethrelease tags for the required version. - Schedule a maintenance window to apply the upgrade to sequencers, validators, and RPC nodes.
- Verify that the new
SystemConfigandL1Blockvalues match the PUP specification.
Operational risks:
- Missing the activation slot causes the chain to diverge from the canonical Superchain state.
- Incorrectly configured batcher or proposer parameters can stall L1 data posting.
Chainscore can provide upgrade readiness reviews that verify node configurations, testnet rehearsal results, and rollback procedures before mainnet activation.
Operational Impact of a Mandatory Upgrade
A mandatory protocol upgrade proposal (PUP) creates a hard deadline for all OP Stack chain operators. The operational impact spans node infrastructure, bridge security, and integration compatibility.
Sequencer and Batcher Coordination
If the upgrade modifies derivation rules, channel timeout parameters, or the batch submission format, the sequencer and batcher must be restarted with updated configurations. A misconfigured batcher could submit invalid batches to L1, causing a chain halt. Operators should coordinate the upgrade with their sequencing infrastructure provider and ensure the batcher's L1 gas pricing and data availability posting logic aligns with the new protocol rules.
Indexer and API Compatibility
Changes to the state transition function, receipt format, or gas accounting can break indexers, block explorers, and analytics platforms. Teams running custom ETL pipelines or subgraphs should run a full re-index against the upgraded testnet to detect schema mismatches or missing data. Pay close attention to any new precompile addresses or modified opcode pricing that could alter transaction tracing output.
Security Council Delay and Veto Window
The Security Council can delay a PUP's activation to allow for additional review. Operators must not assume a proposal's execution timestamp is final until the delay period expires without a veto. Build a monitoring alert for the Security Council's on-chain veto event. If a veto is executed, all upgrade preparations must be rolled back, and teams should be ready to redeploy infrastructure to the previous stable release.
Governance and Upgrade Risks
Risk matrix for the OP Stack upgrade governance path, identifying failure modes, affected actors, and required actions from proposal submission through Security Council activation.
| Risk | Failure mode | Severity | Mitigation |
|---|---|---|---|
Upgrade key compromise | Malicious PUP approved via compromised Foundation multisig or Security Council keys | Critical | Monitor Security Council composition and key management proposals; verify multisig threshold and signer diversity |
Governance capture | Concentrated OP voting power forces through a PUP that benefits a single actor at the expense of the Superchain | High | Track delegation concentration and vote outcomes; review proposal for protocol-level value extraction vectors |
Security Council veto failure | Council fails to exercise veto on a malicious or buggy PUP within the activation delay window | Critical | Verify Security Council members are active and monitoring; ensure monitoring infrastructure alerts on all proposed upgrades |
Activation delay bypass | PUP is executed before the mandatory delay period expires due to a flaw in the timelock or governance contracts | Critical | Audit the timelock contract logic; confirm the delay period is enforced onchain and not configurable by a single role |
Incomplete specification review | Chain operators approve a PUP without fully understanding a breaking change to derivation or state transition | High | Require technical specification and impact analysis for every PUP; Chainscore can provide independent upgrade readiness reviews |
Superchain fragmentation | A PUP introduces an optional change that causes behavioral divergence between OP Mainnet and other OP Stack chains | Medium | Assess PUP for Superchain-wide compatibility; verify against the Law of Chains standard and canonical OP Stack spec |
Emergency upgrade abuse | The Security Council uses emergency powers to push an upgrade without the standard delay, bypassing community review | High | Define clear emergency criteria; monitor all emergency upgrade events and require post-hoc justification and review |
Chain Operator Upgrade Readiness Checklist
A structured checklist for OP Stack chain operators to validate readiness before a Protocol Upgrade Proposal (PUP) reaches its activation deadline. This covers the critical path from governance approval to node software deployment.
Track the PUP from the initial governance proposal through Security Council deliberation to final approval. The Security Council has a built-in activation delay and veto window, making the exact activation block or timestamp a moving target until the delay expires.
- What to check: The status of the onchain governance proposal, Security Council deliberation phase, and the final activation timestamp or block number.
- Why it matters: Missing the activation deadline results in a chain halt or a hard fork away from the Superchain, breaking cross-chain messaging and bridge functionality.
- Readiness signal: Your team has a documented process to monitor the Optimism Governance forum, the Security Council's veto window, and the final
op-geth/op-noderelease tags for the upgrade.
Canonical Resources
Use these primary sources to track how an OP Stack protocol upgrade proposal moves from specification to governance approval, activation, and operator rollout. Teams should verify proposal status, activation timing, and implementation requirements against canonical Optimism resources before taking production action.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Common operational questions from core developers, chain operators, and infrastructure teams preparing for a Protocol Upgrade Proposal (PUP) activation on the Superchain.
The process typically flows through these stages:
- Specification Drafting: Core developers publish a technical specification detailing the proposed changes to the OP Stack.
- Governance Proposal: The specification is formalized into a governance proposal, often a Protocol Upgrade Proposal (PUP), and submitted to the Token House for a vote.
- Veto Period: If approved by the Token House, the proposal enters a waiting period where the Citizens' House can exercise its veto power.
- Security Council Activation: If not vetoed, the Security Council queues the upgrade for onchain execution. The Security Council's multisig initiates the upgrade transaction, which is subject to a mandatory activation delay.
- Protocol Upgrade: After the delay, the upgrade is executed onchain, and node operators must have updated their client software to remain in consensus.
Teams should verify the current status of any specific proposal against the canonical Optimism Governance Calendar.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


