Maintenance Upgrade Proposal: U16a

Technical Proposals 📃
1

Proposal Type: Maintenance Upgrade

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

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

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

Executive Summary

  • **Upgrade 16a is a maintenance upgrade that replaces Upgrade 16**.

  • The primary purpose of U16a is to temporarily remove interop withdrawal-proving code that was introduced in U16 but not actually enabled on mainnet in response to feedback from partners (example 1, 2, 3).

  • All interop-related code remains in the Optimism Monorepo, and we remain committed to shipping interop in a future upgrade.

  • U16a also introduces system-level feature toggles via the SystemConfig contract, allowing the OP Stack to ship more iteratively and customize features per chain going forward.

  • There are no other significant changes beyond these adjustments.

Motivation

The Optimism Collective’s vision includes a decentralized, interoperable Superchain that enables seamless, secure cross-chain experiences. U16 introduced the first wave of interop-ready contracts.

After releasing U16, OP Labs received feedback from a number of key partners indicating concern about certain aspects of U16, particularly the introduction of the ETHLockbox contract which results in a transfer of all of the ETH in the chain’s existing OptimismPortal contract to a net-new ETHLockbox contract.

OP Labs has made the determination that the best pathway forward is to temporarily remove a few interop-specific code paths that were not enabled in production (1, 2, 3). This allows us to:

Notably, U16a officially introduces a model for customizable system features, which allows chains currently utilizing the ETHLockbox to retain that functionality for chains that already have the contract while not requiring this feature while Superchain Interop is still in development.

Our experience with U16a has led to a significant and immediate shift in the way that OP Labs develops and validates upgrade proposals. Chain partners who would be most impacted by any particular change to the protocol are now included at the earliest stage of development for each new feature. U16a’s customizable system feature model also lays the groundwork for being able to develop new features going forward that do not necessarily need to be adopted by all chains.

Specifications

Blockspace Charter

  • This upgrade requires a number of small modifications to the Standard Rollup Charter.

    • The OP Contracts Manager address is updated to 0x8123739c1368c2dedc8c564255bc417feeebff9d and the latest release tag is op-contracts/v4.1.0-rc.3 and corresponds to the commit 594bc933a38425f745b46399a3619bcdeb74965d in the Optimism Monorepo

  • The most recent version can be found here.

  • PR to update the Standard Rollup Charter can be found here:

Key Changes in U16a

  • Interop Withdrawal-Proving Code Removed

    • Interop-specific code for withdrawals are removed in the mainline contracts (1, 2, 3).

    • ETHLockbox remains supported for chains already on U16.

    • Chains skipping directly from U15 → U16a will not adopt ETHLockbox until a future upgrade.

  • System-Level Feature Toggles Introduced

  • Development Feature Flags

    • Added to enable deploying and testing upcoming interop functionality without impacting production chains.

    • These flags cannot be set on production environments.

  • OPContractsManager (OPCM) Updates

    • Supports both upgrade paths: U15 → U16a and U16 → U16a.

Technical Details

Audits and Security Reviews

  • Existing U16 audits remain valid where code is unchanged.

  • U16a has been audited by Spearbit.

    • 1 Low related to code behind a development feature flag that would not run in production. We have addressed this issue as part of U17.

    • 1 Low related to a way in which a OP Stack ProxyAdmin could potentially cause the system to unintentionally become unpaused (if already paused) if the new feature flag system is misused. We are planning to close this footgun as part of U17.

    • Report can be found here.

  • As with U16, the calldata and code for this governance proposal are in scope for the Optimism bug bounty on Immunefi as of the publication of this post.

Absolute Prestate

U16a uses the same absolute prestate as U16 because U16a does not include any update to op-program or to the L2 state transition function. Section below is copied from U16 for completeness.

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

  • No expected downtime.

  • Does not materially change the behavior of the protocol for end users, infra providers, or chain governors.

  • No invalidation of existing withdrawal proofs for chains that are already on U16. Chains that are still on U15 are subject to the same impact summary as the original U16 proposal.

  • For chains skipping directly from U15 to U16a, ETHLockbox adoption is deferred until a future upgrade.

  • Operators will benefit from the new system-level feature toggling, which will improve rollouts subsequent upgrades.

Precommitment Impact Review

Upgrade 16a 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 (part of U16, not U16a), 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 October 2nd, 2025. The upgrade will be executed using OPContractsManager (OPCM) version v4.1.0. The source code for this release is available at op-contracts/v4.1.0-rc.3. The mainnet deployment address for the OPCM is 0x8123739c1368c2dedc8c564255bc417feeebff9d and is also available in the superchain-registry.

Upgrade Transaction Commitments

The following data will be used by the relevant multisigs as a DELEGATECALL to the Multicall3DelegateCall contract on Ethereum targeting the OPCM address above. If target and calldata in the runbooks prepared for the upgrade do not match, they should not be executed.

  1. To upgrade OP Mainnet, Ink, and Soneium

    0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000008123739c1368c2dedc8c564255bc417feeebff9d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000164ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000003000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb290000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb0403eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e8364000000000000000000000000d56045e68956fce2576e680c95a4750cf8241f7903eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc80000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000089889b569c3a505f3640ee1bd0ac1d557f436d2a03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000

  2. To upgrade Unichain

    0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000008123739c1368c2dedc8c564255bc417feeebff9d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda60000000000000000000000003b73fa8d82f511a3cae17b5a26e4e1a2d5e2f2a403eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000

  3. To upgrade Base

    0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000008123739c1368c2dedc8c564255bc417feeebff9d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a10000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000073a79fab69143498ed3712e519a88a918e1f40720000000000000000000000000475cbcaebd9ce8afa5025828d5b98dfb67e059e03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc800000000000000000000000000000000000000000000000000000000

Software Updates

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

  • op-node: op-node/v1.13.6

  • op-geth: op-geth/v1.101602.0

For chain operators running Fault Proofs, ensure you are running up-to-date versions of the following:

  • op-challenger: op-challenger/v1.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 16a is the start of a more iterative approach to delivering new features that might not be adopted by all OP Stack operators.

We request the Optimism Collective’s approval for this upgrade, which enables us to keep shipping safely while moving towards the Superchain vision.

—

Edit Log

  • 2025-09-19: Added Spearbit audit report link.
8 Likes
2

As a member of the Developer Advisory Board and a delegate with sufficient voting power, ACK, LGTM. This is a maintenance upgrade; no expected downtime and no invalidation of existing withdrawal proofs for chains that are already on U16.

7 Likes
3

The Developer Advisory Board completed a review of the U16a maintenance upgrade. As this is a maintenance upgrade, a formal DAB vote was not required. Anyway, all 7 voting members and the Lead participated in a full review of the proposal. Our review process involved providing feedback on the initial draft, and reviewing the upgrade PR links and audit.

The board was unanimously in support of this upgrade :white_check_mark:

Broader Ecosystem Alignment

A strategic point was made about the importance of having a clear sense of how other chains in the Superchain ecosystem view these upgrades. If you’re a stakeholder for a chain on the OP Stack, DM me, the DAB would love to connect!

Conclusion

The DAB is confident in the U16a upgrade and appreciates the collaborative process with OP Labs! Thanks @kelvin and team, and thank you DAB members for your work on our first upgrade review!

4 Likes