Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon

Technical Proposals 📃 Protocol Upgrade
1

Proposal Type: Protocol Upgrade

Hi, I’m Kelvin, the technical lead on the OP Labs EVM Safety team. I will be acting as the primary point of contact for technical questions related to this proposal.

The following proposal was prepared by various engineers and program managers at OP Labs and has received preliminary review from the Developer Advisory Board. Neither OP Labs nor I or any other entity mentioned represent or speak on behalf of the Optimism Foundation.

This proposal is will run off-cycle, as outlined in the Operating Manual

Executive Summary

  • Upgrade 16 prepares for Superchain interop. It includes all of the smart contract changes required to support the interop launch date, but does not turn interop on yet.
  • Upgrade 16 increases OP Stack decentralization and security by removing a permissioned role and guaranteeing that the OP Stack continues to meet L2Beat’s updated Stage 1 criteria.
  • Upgrade 16 includes a number of additional maintenance features and improvements to the OP Stack experience.
    • Cannon is being updated to support Go 1.23, which allows the OP Stack to stay up to date with upstream changes to go-ethereum.
    • OP Stack chains can now scale further with an increase in the maximum allowed gas limit from 200 million gas per block to 500 million gas per block after recent improvements to the OP Stack proof system and other related infrastructure.

Motivation

The Optimism Collective’s vision includes a decentralized, interoperable Superchain that allows users and developers to move freely and securely across chains.

Prepare for Interop

Interoperability is critical to realizing the Superchain as a unified network of OP Chains. By upgrading contracts to support key interop features, we lay the foundation to more easily and securely turn interop on.

Increase Decentralization and Security

We want to minimize trust assumptions wherever possible to build a better Superchain. This upgrade removes a permissioned role and ensures that the OP Stack will continue to meet L2Beat’s updated Stage 1 requirements from January 2025.

Go 1.23 support in Cannon

Because the OP Stack’s op-geth was upgraded to require Go 1.23, Cannon has been upgraded to support it.

Kona support in Cannon

Kona provides an OP Stack state transition proof SDK written in Rust, and Kona is now supported in Cannon. Diversity of proof systems is important to the resiliency of the OP Stack. Before Kona, there was only op-program, written in Go.

Increase MAX_GAS_LIMIT

MAX_GAS_LIMIT exists so that chain operators don’t configure block gas limit to an amount that’s too large to be fault-provable. With the release of MT Cannon in Upgrade 14, this limit can now be safely increased. This extended configurability may serve OP Stack deployments that need a very large yet fault-provable gas limit.

Specifications

Blockspace Charter

Technical Details

Interop-Ready Smart Contracts

Documentation

Description

Upgrade 16 updates the core bridge contracts of the OP Stack to be able to support native interoperability between two OP Stack chains. Although Upgrade 16 does not turn interop on, it includes all of the smart contract changes required to support the interop launch date.

Modifications required for interop readiness included the following improvements to the stack:

  • The OptimismPortal now relies on the AnchorStateRegistry as the “source of truth” for the validity of dispute games that can be used to execute withdrawals. This was necessary so that multiple OptimismPortal contracts within the Interop Set could share a common source of truth (instead of each OptimismPortal having its own view of the system).
  • The OptimismPortal now stores ETH in a dedicated ETHLockbox contract rather than holding ETH within the OptimismPortal itself. This change introduces the possibility for chains to eventually pool their ETH into a single ETHLockbox contract, which means that ETH that gets deposited into one chain can be withdrawn from another chain.
    • Without a shared ETHLockbox it would be possible to transfer ETH from one L2 to another, but it would not always be possible to withdraw that ETH back to Ethereum. A shared ETHLockbox contract solves this problem.
    • Shared ETHLockbox contracts are only useful after interop goes live (in a future upgrade). This upgrade DOES NOT introduce any shared lockbox contracts. Each chain after Upgrade 16 will still have its own independent ETHLockbox. Future governance actions will deal with any proposals to join lockboxes into a shared lockbox.
  • The OptimismPortal now has a version of the proveWithdrawalTransaction function that supports the updated SuperFaultDisputeGame implementation required for interop. "this method will be enabled when we turn interop on in Upgrade 17.

Stage 1 Updates

Documentation

Description

Upgrade 16 includes updates to the OP Stack that make sure it’ll continue to meet L2Beat’s updated Stage 1 requirements from January 2025.

  • The DeputyGuardianModule has been removed. This means that the Security Council is now the only address that is allowed to perform Guardian-only actions by default. This includes actions that invalidate dispute games.
  • The DeputyPauseModule has been updated so that it can be installed into the Security Council’s Guardian Safe. The DeputyPauseModule is otherwise unmodified and allows the Optimism Foundation to trigger the pause action.
  • The pause action expires automatically after 3 months. This 3 month value was selected in coordination with L2Beat and implies a maximum pause period of 6 months (by utilizing the chain-specific pause and then the Superchain-wide pause back-to-back). The Optimism Foundation cannot trigger the pause more than once unless the Security Council explicitly allows it to do so. This means that an indefinite pause of the bridge system for OP Mainnet and other Optimism-governed chains is only possible if ≥75% of the Security Council approves (whereas this is currently possible if ≥25% of the Security Council refuses to unpause).
  • The pause action can now be applied on a per-chain basis as well as a Superchain-wide basis, minimizing the impact of the pause mechanism if an issue would only impact one specific chain. Various contracts have been updated to read the status of the pause via the SystemConfig contract instead of the SuperchainConfig contract to account for this new chain-specific pause mechanism.
  • Overall, this is a major improvement to the OP Stack. It simplifies the stack such that (in the absence of a bug) withdrawal liveness failures and withdrawal safety failures require ≥75% of the Security Council. Upgrade 16 represents a significant decentralization step and a removal of all unilateral Optimism Foundation actions other than a time-bounded pause that automatically expires after 3 months.

Go 1.23 Support in Cannon

Documentation

Description

  • Cannon, the Fault Proof VM, has been updated to be able to support Go 1.23. This means the OP Stack can keep benefiting from upstream changes in go-ethereum.

Kona Support in Cannon

Documentation

Description

  • Kona is an alternative Fault Proof Program, i.e. an alternative to op-program, written in Rust. Cannon, the Fault Proof VM, has been updated to be able to run Kona, in order to increase the diversity of proofs systems that are supported.

Max Gas Limit Increase

Documentation

Description

  • The MAX_GAS_LIMIT variable in the SystemConfig contract is being updated from 200m gas to 500m gas after updates to OP Stack infrastructure and the Cannon proof system have made it possible for chains to safely increase the gas limit beyond 200 million gas per block.

Additional Safety Improvements

  • Critical functions for contract upgrades (initialize and upgrade) are now authenticated and can only be triggered by the same account that is able to upgrade the contracts. This mitigates the risk of a contract being left in a state where upgrade or initialize could be called by a malicious third party.
  • The DelayedWETH contract no longer has an owner variable and is now controlled by the upgrade account (this cannot be changed without a contract upgrade). This is a simplification to the DelayedWETH contract and prevents chains from misconfiguring the contract’s owner.
  • This upgrade introduces a new StandardValidator contract, which encodes the standard configuration. It can inspect and OP Chain, and will return a list of error codes identifying any deviations from the standard configuration.

Audits and Security Reviews

  • Changes to the bridge contracts to support interop were audited as part of a contest held operated via Cantina. This contest found no Medium+ severity issues. Some Low severity issues were fixed as part of this contest.
  • Upgrade 16 as a whole was audited by Spearbit. This audit found no Medium+ severity issues. Some Low severity issues were fixed as part of this audit.
  • The calldata and code for this governance proposal are in scope for the Optimism bug bounty in Immunefi (as described in the Governance Proposals section). With recent updates, this code is in scope for the bounty as of the publication of this post, BEFORE this code is live on mainnet.

Absolute Prestate

This upgrade includes the absolute prestate for op-program v1.6.1-rc.1. The full diff between v1.6.0 and v1.6.1-rc.1 can be inspected here. The absolute prestate hash (cannon64 variant) is 0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8. It has been publicly verified here.

Impact Summary

Upgrade 16 is a largely standard upgrade to the L1 smart contracts for the OP Stack. We do not expect any downtime or changes in performance.

Upgrade 16, like Upgrade 13, involves a one-time invalidation of all existing withdrawal proofs. This invalidation is the simplest and safest way to carry out the proposed changes to the AnchorStateRegistry contract. Users who have proven withdrawals can either finalize withdrawals prior to the activation of Upgrade 16 or will be required to re-prove these withdrawals after the upgrade activates.

Precommitment impact review

Upgrade 16 does not impact any of the precommitments included in the Standard Rollup Charter as of the writing of this proposal.

  • “Collective Fee Take” - unchanged
  • “Governor/Servicer Role Separation” - unchanged
  • “Ossified GasLimits” - gas limit is increased, but gas limit continues to not be ossified and the changes in this proposal fall within the bounds of the precommitment
  • “Direct Fee Margin Controls” - unchanged

Action Plan

If this proposal is accepted, the upgrade is expected to take place on July 24, 2025. In that case, mulitisig ceremonies will be coordinate such that the following transactions will be executed.

The upgrade will be executed using OP Contracts Manager (OPCM) version 4.0.0:

  • The OPCM source code for this release is available at op-contracts/v4.0.0-rc.8.

  • The mainnet deployment address for the OPCM is available in the superchain-registry: 0x56ebc5c4870f5367b836081610592241ad3e0734

  • Upgrade transaction commitments

    All of the following data will executed by the relevant multisigs as a DELEGATECALL to Multicall3DelegateCall. If target and calldata in the runbooks prepared for executing the upgrade do not match, they should not be executed.

    1. To upgrade OP Mainnet and Ink

      0x82ad56cb00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000056ebc5c4870f5367b836081610592241ad3e0734000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000104ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000002000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb290000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb0403eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e8364000000000000000000000000d56045e68956fce2576e680c95a4750cf8241f7903eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000

    2. To upgrade Soneium

      0x82ad56cb00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000056ebc5c4870f5367b836081610592241ad3e07340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a1000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000089889b569c3a505f3640ee1bd0ac1d557f436d2a03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000

    3. To upgrade Unichain

      0x82ad56cb00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000056ebc5c4870f5367b836081610592241ad3e07340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda60000000000000000000000003b73fa8d82f511a3cae17b5a26e4e1a2d5e2f2a403eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000

Node operators should ensure they are running up-to-date versions of op-node and op-geth:

For chain operators running fault-proof infrastructure, ensure you are running up-to-date versions of the following:

If a critical security issue is discovered before upgrading, OP Labs will collaborate with the community to extensively communicate that the upgrade will no longer occur.

Conclusion

Upgrade 16 represents a major step towards the launch of interoperability on the OP Stack.

The key components of this upgrade include:

  • Implementation of the interoperability features into the L1 bridging system
  • Various system tweaks required to retain Stage 1 status
  • Go 1.23 support in Cannon
  • Other security improvements

While this upgrade does require an invalidation of existing withdrawal proofs, the impact on users is minimal and temporary. The upgrade has been thoroughly tested and audited, with no significant security concerns identified.

We request the Optimism Collective’s approval for this upgrade, as it represents a crucial step forward in our ongoing mission to improve the OP Stack.

Edit Log

  • 2025-06-20: Added Precommitments section to highlight that none of the commitments in the Standard Rollup Charter are impacted by this proposal.
  • 2025-06-20: Updated to note that the OPContractsManager address and the gas limit are being updated in the Standard Rollup Charter and included a link to the PR that makes this update.
  • 2025-06-23: In “Go 1.23 Support in Cannon”, added links to GitHub pull requests #16341, #16346, #16384, and the audit in pull request #16479
  • 2025-06-23: Added “Absolute Prestate” section to note the value of the updated absolute prestate for the fault proof system.
  • 2025-07-08: Updated link for OPContractManager address on Mainnet.
27 Likes
2

Exciting! So great to see this proposal.

2 Likes
3

Hi all, on behalf of the DAB, we’re trying our best in our collab with Labs to bring out the “why” behind each upgrade feature. The collab started with upgrade 16, and we need your feedback to iterate. Whether you’re technical or non-technical, if this proposal is not clear to you (executive summary, motivations, etc) please reach out and let us know.

8 Likes
4

Adding a procedural note that this upgrade will follow the same protocol upgrade process as the Collective has followed before. The new governance process for Protocol Upgrades will begin August 1st, once a new Developer Advisory Board has been elected. That means this proposal will require the usual 76% approval in the Token House, followed by a one-week veto period in the Citizens’ House (subject to veto by the Season 7 Citizens.)

1 Like
5

Hey ED, I do have one question, probably due to my own ignorance, and I don’t think there’s anything wrong with the proposal.

As I understand it, withdrawals from L2 to L1 are only finalized after a proof is posted and survives the fault challenge window. These proofs rely on a prestate hash, which is basically a snapshot of the L2 execution environment (or at least that’s how I understand it). With this upgrade introducing a new absolute prestate (0x03eb…), does that mean all previously submitted withdrawal proofs become “invalid” because they were based on the older prestate?

If that’s correct, users or apps who already submitted a proof and are waiting out the challenge window might get caught off guard if their proof no longer works. Wouldn’t that introduce a coordination risk?

It also seems to show that dispute game upgrades aren’t backward compatible, which might be worth documenting somewhere as a known constraint.

Would it make sense for the DAB to surface some guidance or fallback path for any app or user that ends up affected? Or even recommend a short advisory window where apps avoid posting new proofs close to the upgrade time?

Again, sorry if this is wasting anyone’s time, the upgrade looks amazing for my ignorant eyes.

5 Likes
6

With this upgrade introducing a new absolute prestate (0x03eb…), does that mean all previously submitted withdrawal proofs become “invalid” because they were based on the older prestate?

Great question. A prestate update alone typically does not cause all previously submitted dispute games to become invalid. However, in this case, because of a number of ways in which the OptimismPortal is changing, we felt that explicitly invalidating previous dispute games was the safest approach. An explicit invalidation decreases the risk of a mistake in the upgrade process that could potentially cause older invalid games to become valid again.

If that’s correct, users or apps who already submitted a proof and are waiting out the challenge window might get caught off guard if their proof no longer works. Wouldn’t that introduce a coordination risk?

This is correct, but Upgrade 16 isn’t the first time this has happened (last time was Upgrade 13), so many apps and interfaces are already prepared for this to happen. For example, superbridge.app will try to prevent users from creating new withdrawals during the week leading up to the upgrade to make sure their proofs aren’t invalidated after the upgrade executes. OP Labs would coordinate with these apps/interfaces to make sure that they’re aware and prepared for this again.

It also seems to show that dispute game upgrades aren’t backward compatible, which might be worth documenting somewhere as a known constraint.

Most dispute game upgrades actually are backwards compatible. A simple prestate changes, for instance, does not require that existing games be invalidated. The last few upgrades have involved deeper modifications to the dispute game system that required invalidation for safety reasons (in service of interop) but we should be able to mostly avoid this once the system architecture settles post-interop.

Would it make sense for the DAB to surface some guidance or fallback path for any app or user that ends up affected? Or even recommend a short advisory window where apps avoid posting new proofs close to the upgrade time?

It’s likely sufficient for OP Labs to do this again because we’ve done it in the past, but would be happy to walk the DAB through more context as a way to spread knowledge across the ecosystem if desired!

7 Likes
7

Happy to see us take a leap towards the InterOp vision
Thanks OP Labs for putting this together.

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like
8

Key Dates for off cycle Proposal

Review Period : June 20 – July 2
Voting Period : July 3 – 9
Veto Period : July 10 – 16

2 Likes
9

The SEEDGov delegation, as we’ve communicated here, being an Optimism delegation with sufficient voting power, we believe this proposal is ready to move towards a vote.

1 Like
10

Exciting upgrade happy to see progress every month in superchain lfg guys!

1 Like
11

We are an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

12

I agree with this prop. great

13

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like
14

We are an Optimism Delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

1 Like
15

I am an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

1 Like
16

I am one of the Synthetix Ambassadors, and I am an Optimism Top 100 delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote

17

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

18

The following reflects the views of L2BEAT’s governance team, composed of @kaereste, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

We voted FOR the proposal.

Given that the proposal is a technical upgrade, we consulted L2BEAT’s research team, and they helped us review the proposed changes and their effect. The upgrade focuses on three main changes:

  • Introduction of interop-ready contracts, without, however, activating them.
  • Removal of the Deputy Guardian role to keep the Stage 1 designation
  • General maintenance, including an increment of the maximum safe gas limit from 200 Mgas to 500 Mgas.

We find all the changes sensible and welcome, and therefore we’re voting in favor of the proposal. We also shared a more detailed breakdown of the proposed changes as an X thread, which can be found here.

2 Likes
20

Thanks for the deep dive in this topic.