# Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon **URL:** \ **Category:** Protocol Upgrade\ **Created:** [June 20, 2025, 6:17pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037 "2025-06-20T18:17:45Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![kelvin](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/kelvin/32/3162_2.png) [@kelvin](https://gov.optimism.io/u/kelvin)\ **Post date:** [June 20, 2025, 6:17pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/1 "2025-06-20T18:17:45Z")
# **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](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)**_ # **Executive Summary** - Upgrade 16 prepares for Superchain [interop](https://specs.optimism.io/interop/overview.html). 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](https://forum.l2beat.com/t/stages-update-a-high-level-guiding-principle-for-stage-1/338). - Upgrade 16 includes a number of additional maintenance features and improvements to the OP Stack experience. - [Cannon](https://specs.optimism.io/fault-proof/cannon-fault-proof-vm.html) is being updated to support [Go 1.23](https://tip.golang.org/doc/go1.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](https://specs.optimism.io/interop/overview.html) 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](https://forum.l2beat.com/t/stages-update-a-high-level-guiding-principle-for-stage-1/338) 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](https://github.com/op-rs/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](https://gov.optimism.io/t/upgrade-proposal-14-isthmus-l1-contracts-mt-cannon/9796/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** - This upgrade requires a number of small modifications to the Standard Rollup Charter. - We are proposing to update the Standard Rollup Charter such that the gas limit is increased to 500m and the OP Contracts Manager address is updated to `0x56ebc5c4870f5367b836081610592241ad3e0734` and the latest release tag is `op-contracts/v4.0.0-rc.8` and corresponds to the commit `54c19f6acb7a6d3505f884bae601733d3d54a3a6` in the Optimism Monorepo - The most recent version can be [found here](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Standard%20Rollup%20Charter.md). - PR to update the Standard Rollup Charter can be found here: - [Update Standard Rollup Charter for Upgrade 16 by smartcontracts · Pull Request #50 · ethereum-optimism/OPerating-manual · GitHub](https://github.com/ethereum-optimism/OPerating-manual/pull/50) ## Technical Details ### Interop-Ready Smart Contracts **Documentation** - [Design document](https://github.com/ethereum-optimism/design-docs/pull/205) - Specification ([1](https://github.com/ethereum-optimism/specs/pull/603), [2](https://github.com/ethereum-optimism/specs/pull/569)) - Implementation ([1](https://github.com/ethereum-optimism/optimism/pull/13824), [2](https://github.com/ethereum-optimism/optimism/pull/14588), [3](https://github.com/ethereum-optimism/optimism/pull/14532)) - Failure mode analysis ([1](https://github.com/ethereum-optimism/design-docs/blob/main/security/fma-eth-lockbox.md), [2](https://github.com/ethereum-optimism/design-docs/pull/255)) **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** - [Design document](https://github.com/ethereum-optimism/design-docs/pull/202) - [Specification](https://github.com/ethereum-optimism/specs/pull/625) - [Implementation](https://github.com/ethereum-optimism/optimism/pull/15174) - [Failure mode analysis](https://github.com/ethereum-optimism/design-docs/pull/258) **Description** Upgrade 16 includes updates to the OP Stack that make sure it’ll continue to meet L2Beat’s [updated Stage 1 requirements](https://forum.l2beat.com/t/stages-update-a-high-level-guiding-principle-for-stage-1/338) 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** - Implementation: - [https://github.com/ethereum-optimism/optimism/pull/14692](https://github.com/ethereum-optimism/optimism/pull/14692) - [cannon: Add feature toggling to MIPS VM contracts by mbaxter · Pull Request #15487 · ethereum-optimism/optimism · GitHub](https://github.com/ethereum-optimism/optimism/pull/15487) - [https://github.com/ethereum-optimism/optimism/pull/15664](https://github.com/ethereum-optimism/optimism/pull/15664) - [cannon: Noop mprotect syscall by Inphi · Pull Request #15792 · ethereum-optimism/optimism · GitHub](https://github.com/ethereum-optimism/optimism/pull/15792) - [https://github.com/ethereum-optimism/optimism/pull/16341](https://github.com/ethereum-optimism/optimism/pull/16341) - [https://github.com/ethereum-optimism/optimism/pull/16346](https://github.com/ethereum-optimism/optimism/pull/16346) - [cannon: Enforce the non-block flag for eventfd syscalls by mbaxter · Pull Request #16384 · ethereum-optimism/optimism · GitHub](https://github.com/ethereum-optimism/optimism/pull/16384) - [Add report for the Cannon Go 1.23 support fix by pauldowman · Pull Request #16479 · ethereum-optimism/optimism · GitHub](https://github.com/ethereum-optimism/optimism/pull/16479) - [Failure mode analysis](https://github.com/ethereum-optimism/design-docs/pull/279) **Description** - Cannon, the [Fault Proof VM](https://specs.optimism.io/fault-proof/cannon-fault-proof-vm.html), 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** - [Implementation](https://github.com/ethereum-optimism/optimism/pull/14454) - [Failure mode analysis](https://github.com/ethereum-optimism/design-docs/pull/279) **Description** - [Kona](https://github.com/op-rs/kona) is an alternative [Fault Proof Program](https://specs.optimism.io/fault-proof/index.html#fault-proof-program), i.e. an alternative to op-program, written in Rust. Cannon, the [Fault Proof VM](https://specs.optimism.io/fault-proof/cannon-fault-proof-vm.html), 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** - [Implementation](https://github.com/ethereum-optimism/optimism/pull/15864) **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](https://specs.optimism.io/protocol/configurability.html?highlight=standard%20config#consensus-parameters). It can inspect and OP Chain, and will return a list of [error codes](https://github.com/ethereum-optimism/optimism/blob/0c5768017404fac9a88c8c190ad3e773cb315bf7/op-validator/pkg/validations/codes.go#L1) 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](https://cantina.xyz/competitions/44b385bf-e51a-4e6c-b3a8-adbbe24d16e1) held operated via Cantina. This contest found no Medium+ severity issues. Some [Low severity issues were fixed](https://github.com/ethereum-optimism/optimism/pull/15513) as part of this contest. - Upgrade 16 as a whole was [audited by Spearbit](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2025_05-Interop-Portal-Spearbit.pdf). This audit found no Medium+ severity issues. Some [Low severity issues were fixed](https://github.com/ethereum-optimism/optimism/pull/15939) as part of this audit. - **The calldata and code for this governance proposal are in scope for the [Optimism bug bounty in Immunefi](https://immunefi.com/bug-bounty/optimism) (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](https://github.com/ethereum-optimism/optimism/releases/tag/op-program%2Fv1.6.1-rc.1). The [full diff between v1.6.0 and v1.6.1-rc.1 can be inspected here](https://github.com/ethereum-optimism/optimism/compare/op-program/v1.6.0...op-program/v1.6.1-rc.1). The absolute prestate hash (cannon64 variant) is [`0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8`](https://github.com/ethereum-optimism/superchain-registry/blob/6b65f330434d46e24abc9ef78852ac3fa1cba4ec/validation/standard/standard-prestates.toml#L6-L7). It has been publicly verified [here](https://www.notion.so/U16-Update-Cannon-for-go1-23-1f4f153ee1628012beb5f016a3bfef0a?pvs=21). ### 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](https://github.com/ethereum-optimism/OPerating-manual/blob/5edcb46326b8c7d48c5fde8371245378052e2cee/Standard%20Rollup%20Charter.md#precommitments) 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](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv4.0.0-rc.8). - The mainnet deployment address for the OPCM is [available in the superchain-registry](https://github.com/ethereum-optimism/superchain-registry/blob/6621a0f13ce523fe1bb8deea739fe37abe20f90d/validation/standard/standard-versions-mainnet.toml#L22): `0x56ebc5c4870f5367b836081610592241ad3e0734` - Upgrade transaction commitments Node operators should ensure they are running up-to-date versions of op-node and op-geth: - op-node: [`op-node/v1.12.2`](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.12.2) - op-geth: [`op-geth/v1.101503.1`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101503.1) For chain operators running fault-proof infrastructure, ensure you are running up-to-date versions of the following: - op-challenger: [op-challenger/v1.5.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger%2Fv1.5.1) 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. ---
**Author:** ![Michael](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/michael/32/2489_2.png) [@Michael](https://gov.optimism.io/u/Michael)\ **Post date:** [June 20, 2025, 6:50pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/2 "2025-06-20T18:50:57Z")
Exciting! So great to see this proposal. ---
**Author:** ![wildmolasses](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/wildmolasses/32/11299_2.png) [@wildmolasses](https://gov.optimism.io/u/wildmolasses)\ **Post date:** [June 20, 2025, 8:44pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/3 "2025-06-20T20:44:34Z")
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. ---
**Author:** ![system](https://europe1.discourse-cdn.com/bc41dd/original/2X/3/399c2cdab1be9e0c1ae7481c939f977574c28f5e.svg) [@system](https://gov.optimism.io/u/system)\ **Post date:** [June 20, 2025, 9:15pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/4 "2025-06-20T21:15:17Z")
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.) ---
**Author:** ![Gonna.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gonna.eth/32/3379_2.png) [@Gonna.eth](https://gov.optimism.io/u/Gonna.eth)\ **Post date:** [June 21, 2025, 1:07am UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/5 "2025-06-21T01:07:24Z")
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. ---
**Author:** ![kelvin](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/kelvin/32/3162_2.png) [@kelvin](https://gov.optimism.io/u/kelvin)\ **Post date:** [June 23, 2025, 1:39pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/6 "2025-06-23T13:39:23Z")
> 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! ---
**Author:** ![Luckyhooman.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/luckyhooman.eth/32/1684_2.png) [@Luckyhooman.eth](https://gov.optimism.io/u/Luckyhooman.eth)\ **Post date:** [June 23, 2025, 5:16pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/7 "2025-06-23T17:16:57Z")
Happy to see us take a leap towards the InterOp vision Thanks OP Labs for putting this together. I am an [Optimism delegate](https://vote.optimism.io/delegates/0x0331969e189D63fBc31D771Bb04Ab44227D748D8) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![system](https://europe1.discourse-cdn.com/bc41dd/original/2X/3/399c2cdab1be9e0c1ae7481c939f977574c28f5e.svg) [@system](https://gov.optimism.io/u/system)\ **Post date:** [June 23, 2025, 6:06pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/8 "2025-06-23T18:06:32Z")
Key Dates for off cycle Proposal **Review Period** : June 20 – July 2 **Voting Period** : July 3 – 9 **Veto Period** : July 10 – 16 ---
**Author:** ![SEEDGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/seedgov/32/5202_2.png) [@SEEDGov](https://gov.optimism.io/u/SEEDGov)\ **Post date:** [June 25, 2025, 8:40am UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/9 "2025-06-25T08:40:31Z")
The SEEDGov delegation, as we’ve communicated [here](https://gov.optimism.io/t/seed-latam-delegate-communication-thread/2950/46), being an [Optimism delegation](https://vote.optimism.io/delegates/0x94db037207f6fb697dbd33524aadffd108819dc8) with sufficient voting power, we believe this proposal is ready to move towards a vote. ---
**Author:** ![ImanPJN](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/imanpjn/32/12213_2.png) [@ImanPJN](https://gov.optimism.io/u/ImanPJN)\ **Post date:** [June 25, 2025, 6:16pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/10 "2025-06-25T18:16:15Z")
Exciting upgrade happy to see progress every month in superchain lfg guys! ---
**Author:** ![PGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/pgov/32/10448_2.png) [@PGov](https://gov.optimism.io/u/PGov)\ **Post date:** [June 27, 2025, 11:42pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/11 "2025-06-27T23:42:57Z")
We are an Optimism [delegate](https://gov.optimism.io/t/pgov-delegate-communication-thread/6059) with sufficient voting power and we believe this proposal is ready to move to a vote. ---
**Author:** ![aygul](https://avatars.discourse-cdn.com/v4/letter/a/ccd318/32.png) [@aygul](https://gov.optimism.io/u/aygul)\ **Post date:** [June 29, 2025, 9:27am UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/12 "2025-06-29T09:27:03Z")
I agree with this prop. great ---
**Author:** ![brichis](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/brichis/32/10892_2.png) [@brichis](https://gov.optimism.io/u/brichis)\ **Post date:** [June 30, 2025, 9:21pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/13 "2025-06-30T21:21:57Z")
I am an [Optimism delegate](https://vote.optimism.io/delegates/brichis.eth) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![DAOplomats.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/daoplomats.eth/32/11109_2.png) [@DAOplomats.eth](https://gov.optimism.io/u/DAOplomats.eth)\ **Post date:** [July 1, 2025, 4:51am UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/14 "2025-07-01T04:51:54Z")
We are an Optimism **[Delegate](https://gov.optimism.io/t/daoplomats-delegate-communication-thread/8061)** with sufficient voting power and we believe this proposal is ready to move to a vote. ---
**Author:** ![olimpio](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/olimpio/32/920_2.png) [@olimpio](https://gov.optimism.io/u/olimpio)\ **Post date:** [July 1, 2025, 8:52am UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/15 "2025-07-01T08:52:40Z")
I am an [**Optimism** delegate](https://gov.optimism.io/t/delegate-commitments-old/235/76) with sufficient voting power and we believe this proposal is ready to move to a vote. ---
**Author:** ![mastermojo](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/mastermojo/32/1178_2.png) [@mastermojo](https://gov.optimism.io/u/mastermojo)\ **Post date:** [July 1, 2025, 3:03pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/16 "2025-07-01T15:03:39Z")
I am one of the Synthetix Ambassadors, and I am an Optimism Top 100 delegate [[Delegate Commitments - #65 by mastermojo](https://gov.optimism.io/t/delegate-commitments/235/65)] with sufficient voting power, and I believe this proposal is ready to move to a vote ---
**Author:** ![OPUser](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/opuser/32/179_2.png) [@OPUser](https://gov.optimism.io/u/OPUser)\ **Post date:** [July 1, 2025, 10:53pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/17 "2025-07-01T22:53:33Z")
I am an [Optimism delegate](https://vote.optimism.io/delegates/0x1de2a056508e0d0dd88a88f1f5cdf9cfa510795c) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![Sinkas](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/sinkas/32/6082_2.png) [@Sinkas](https://gov.optimism.io/u/Sinkas)\ **Post date:** [July 9, 2025, 12:55pm UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/18 "2025-07-09T12:55:44Z")
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](https://x.com/l2beatgov/status/1942535720008311031). ---
**Author:** ![Vikthor](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/vikthor/32/12425_2.png) [@Vikthor](https://gov.optimism.io/u/Vikthor)\ **Post date:** [August 23, 2025, 9:15am UTC](https://gov.optimism.io/t/upgrade-16-proposal-interop-contracts-stage-1-and-go-1-23-support-in-cannon/10037/20 "2025-08-23T09:15:16Z")
Thanks for the deep dive in this topic.