Upgrade 17 - Jovian Hardfork and Fusaka Readiness

[geoknee]

Proposal Title: Upgrade 17 Proposal: Jovian Hardfork and Fusaka Readiness

Proposal Type: Protocol Upgrade

This proposal will run off cycle

Hi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP Stack. I reviewed this proposal in collaboration with Paul Dowman, Matt Solomon, Sebastian Stammler and Sanjana Mehta from the OP Labs Team.

This proposal supersedes a recent proposal which has been deprecated, and has two important differences. Firstly, the calldata snippets quoted in the body of the proposal (which were incorrect) have been corrected. Secondly, the scope of the proposal has been expanded to include preparation for an upcoming hardfork on Ethereum mainnet.

Executive Summary

The Jovian hardfork is a proposed network upgrade for OP Stack chains, which will bring several improvements to the way rollup fees are calculated as well as performing a maintenance update to the fault proof virtual machine. It includes the following features:

• Cannon is being updated to support Go 1.24, which allows the OP Stack to stay up to date with upstream changes to go-ethereum (which op-geth is based on)

  • This allows users to continue to be protected by the very latest execution-layer code; both when they transact and when disputes are contended in the fault proof system.

• Minimum Base Fee and Data Availability Footprint Block Limit which allow the L2 base fee to respond more rapidly to changes in block composition, particularly when this implies an increased demand on the rollup’s capacity to batch blocks to the data availability layer.

  • Pricing this demand more accurately will greatly reduce the need for batcher-sequencer throttling, which in turn will prevent users experiencing undesirable priority fee auctions.

  • When priority fee auctions do ensue, the minimum base fee will cause normal, EIP-1559 market conditions to be restored more rapidly.

  • These features will also protect rollup operators from being overloaded with “spam” transactions which otherwise could cause a drop in profitability and denial of service.

• Operator Fee Fix which modifies the existing, optional “operator fee” feature.

  • This allows operator fees to be set to more realistic levels, allowing for rollup operators to recover a fair compensation for generating zk proofs or other costs which otherwise cannot be recovered. This also lays a necessary foundation for delivering the Custom Gas Token feature in a future upgrade.

The Fusaka hardfork (see Meta-EIP 7607) is an upgrade to the Ethereum protocol’s consensus and execution layer which will activate soon on testnets and mainnet, which are the L1 networks that most OP Stack chains derive from. It contains beacon API changes which, if not adapted to, would cause all OP Stack chains to halt. Additionally, the consensus changes on L1 would cause blob DA to be extremely overpriced on L2, which would price out and deny service to users. In particular:

• EIP-7594 (PeerDAS) requires blob transactions to be submitted with “cell proofs” instead of the existing “blob proof” format. It also implies that blob proofs will not be stored or served by L1 beacon nodes. This impacts the way the OP Stack reads and verifies (via derivation) and write (via batch submission) blobs to/from L1.

• A new framework for blob capacity adjustment is introduced by the EIP-7892 (BPO forks). This framework allows for frequent changes to blob parameters. These mini forks thereby modify the formula which dictates the L1 blob base fee – an important quantity which is not exposed in block headers but recorded in L2 state in order to charge user fees.

Fusaka Readiness consists of changes to:

• Node software

• Optimism protocol specifications and

• L1 Fault Proofs smart contract system(s)

to handle activation of the Fusaka hardfork on L1 networks (both testnets and mainnet).

The expected outcome is that OP Stack chains continue to operate as before (they do not halt) when Fusaka activates on their respective L1 chains. This is a critical piece of maintenance affecting all operators and users of OP Stack chains.

Note: We will NOT be activating Osaka (the execution layer component of the Fusaka hardfork) on L2 with this upgrade. That will be part of a future proposal.

Motivation

We are submitting this proposal to a) perform routine maintenance of the fault proof system (following best security practices), b) make improvements to the Optimism protocol (concerning transaction fees) which will improve the transaction fee experience for users and which lower the risk to chain operators and the ecosystem as a whole and c) to defend against breaking changes that’ll be introduced by the L1 Fusaka hardfork.

There are no anticipated conflicts of interest, and we believe the Collective should adopt the proposal so that the optimism protocol can provide increased value to operators and users alike.

Impacted Stakeholders and Expected Outcomes

• All node operators: will be required to update node software in advance of the activation time for U17.

• Users, developers and ecosystem tools: may wish to adapt to the newly populated BlobGasUsed header and transaction receipt field (see the DA footprint block limit feature specifications linked below)

• Chain operators: will have the option of using the (optional, non-standard) operator fee feature with greatly increased utility, but should take care to migrate safely if they are already using this feature (following the instructions on our documentation website).

Specifications

Blockspace Charter

• This upgrade requires a change to the Standard Rollup Charter, as encapsulated by this PR https://github.com/ethereum-optimism/OPerating-manual/pull/63.

• The change to the charter details a new OPCM and an upper limit on the minimum base fee.

Technical details

Minimum Base Fee

• Design Document

• Specs

  • https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/jovian/exec-engine.md#minimum-base-fee

  • https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/jovian/system-config.md#minimum-base-fee-configuration

• Failure Modes Analysis

Data Availability Footprint Block Limit

• Design Document

• Specs

  • https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/jovian/exec-engine.md#da-footprint-block-limit

  • https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/jovian/system-config.md#da-footprint-configuration

  • https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/jovian/l1-attributes.md

• A Threat Modelling exercise was conducted.

Operator Fee Fix

• Design Document

• Specs

• Failure Modes Analysis

Cannon Go 1.24 support

• Audit reports

  • https://github.com/ethereum-optimism/optimism/blob/9feb7229c298226af61dd8c3d50a4ad495dff749/docs/security-reviews/2025_06-Cannon-3DOC.pdf

  • https://github.com/ethereum-optimism/optimism/blob/1fea4f9dd796227e05a2f9b06122a9a865db18dd/docs/security-reviews/2025_10-U17-Spearbit.pdf

• Tracking issue

Fusaka Readiness

• Clarification to the Optimism specifications

• Updating the go-ethereum library code used in the monorepo, via our op-geth fork, to allow L1 Chain Configurations for testnets and mainnet to be referenced.

• Embedding L1 Chain Configuration in the configuration of op-node, op-program and kona

• Perform blob verification without relying on kzg proofs

• Allow blobs to be fetched from the new beacon API endpoint

The changes are described in detail (with links to code changes) in the release notes, which are linked from this notice page on our docs website https://docs.optimism.io/notices/fusaka-notice

These updates incorporate breaking changes to L1’s RPC contents and source-data verification. The strategy employed to handle the breaking changes is to perform a cherry picked upstream merge of geth into op-geth and reth into op-reth, and then to import the new code into the monorepo where it is consumed by op-node and op-program. Additionally, some quality-of-life optimizations and breaking changes are bundled with the criticial ones called out above; however, none of them are consensus critical.

Contract changes

The contracts changes included in this upgrade are summarized in the release notes for op-contracts/v5.0.0.

After the veto period has ended, we will ask the Security Council to sign transactions to update the contracts using OP Contracts Manager, and to establish a new absolute prestate hash for chains using permisionless fault proofs. These transactions must to be executed before the actual Jovian activation to avoid a broken Fault Proofs system after the activation.

Absolute Prestate

This upgrade includes the absolute prestate for op-program/v1.8.0-rc.4. The absolute prestate hash (cannon64 variant) is 0x03caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b. It has been publicly verified here.

Calldata

The expected calldata to sign on OP Mainnet is below. This also includes the upgrade on Soneium Mainnet and Ink Mainnet, as these networks will be upgraded in one superchain-ops task alongside OP Mainnet.

0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000120000000000000000000000000fa1ef97fb02b0da2ee2346b8e310907ab5519449000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000044b0b807eb00000000000000000000000095703e0982140d16f8eba6d158fccede42f04a4c000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb0400000000000000000000000000000000000000000000000000000000000000000000000000000000fa1ef97fb02b0da2ee2346b8e310907ab5519449000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000164ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000003000000000000000000000000229047fed2591dbec1ef1118d64f7af3db9eb290000000000000000000000000543ba4aadbab8f9025686bd03993043599c6fb0403caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b00000000000000000000000062c0a111929fa32cec2f76adba54c16afb6e8364000000000000000000000000d56045e68956fce2576e680c95a4750cf8241f7903caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b0000000000000000000000007a8ed66b319911a0f3e7288bddab30d9c0c875c300000000000000000000000089889b569c3a505f3640ee1bd0ac1d557f436d2a03caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b00000000000000000000000000000000000000000000000000000000

To generate the above calldata:

1. Clone the superchain-ops repository, and use the main branch

2. cd src/tasks/eth/032-U17-main-op-sony-ink

3. Run the below command either as council or foundation:

SIMULATE_WITHOUT_LEDGER=1 just --dotenv-path $(pwd)/.env simulate <council|foundation>

The terminal output will include the calldata and state changes.

The tasks use the OPCMUpgradeV500 template, refer to it to see how the calldata is generated: https://github.com/ethereum-optimism/superchain-ops/blob/main/src/template/OPCMUpgradeV500.sol

There are several other chains which will be upgraded, in bundles, in additional transactions outlined below. The calldata can be verified in the same way as above (in the superchain-ops repository).

Metal, Mode, Zora

0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000fa1ef97fb02b0da2ee2346b8e310907ab5519449000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000164ff2dd5a1000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000030000000000000000000000007bd909970b0eedcf078de6aeff23ce571663b8aa00000000000000000000000037ff0ae34dada1a95a4251d10ef7caa868c7ac9903caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b0000000000000000000000005e6432f18bc5d497b1ab2288a025fbf9d69e2221000000000000000000000000470d87b1dae09a454a43d1fd772a561a03276ab703caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b000000000000000000000000a3cab0126d5f504b071b81a3e8a2bbbf17930d86000000000000000000000000d4ef175b9e72caee9f1fe7660a6ec19009903b4903caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b00000000000000000000000000000000000000000000000000000000

Arena-Z, Swell

0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000fa1ef97fb02b0da2ee2346b8e310907ab5519449000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000104ff2dd5a10000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000200000000000000000000000034a564bbd863c4bf73eca711cf38a77c4ccbdd6a000000000000000000000000eefd1782d70824cbcacf9438afab7f353f1797f003caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b000000000000000000000000d3d4c6b703978a5d24fecf3a70a51127667ff1a40000000000000000000000004c4710a4ec3f514a492cc6460818c4a6a6269dd603caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b00000000000000000000000000000000000000000000000000000000

Unichain

0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000fa1ef97fb02b0da2ee2346b8e310907ab55194490000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000c407398d063f942febbcc6f80a156b47f3f1bda60000000000000000000000003b73fa8d82f511a3cae17b5a26e4e1a2d5e2f2a403caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b00000000000000000000000000000000000000000000000000000000

Base

0x82ad56cb000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000fa1ef97fb02b0da2ee2346b8e310907ab55194490000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a4ff2dd5a10000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000073a79fab69143498ed3712e519a88a918e1f40720000000000000000000000000475cbcaebd9ce8afa5025828d5b98dfb67e059e03caa1871bb9fe7f9b11217c245c16e4ded33367df5b3ccb2c6d0a847a217d1b00000000000000000000000000000000000000000000000000000000

Impact summary

Minimum Base Fee, Data Availability Footprint Block Limit, Operator Fee Fix

These features will be activated by the Jovian hardfork, and will require execution layer, consensus layer, and contracts layer updates. Because the hardfork changes consensus rules, a new absolute prestate will be required for chains running permissionless fault proofs.

We have published a notice page clarifying the required software versions and activation times here https://docs.optimism.io/notices/upgrade-17.

Cannon Go 1.24 support

This feature requires the deployment of a new MIPS contract for chains running permissionless fault proofs.

Fusaka Readiness

We do not anticipate any downtime due to this upgrade, as long as it is executed on each chain before Ethereum activates Fusaka. There should be no impact on performance after the upgrade.

As long as the upgrade is executed in this manner, there will be no risk of chain splits. Operators should upgrade their node software as soon as possible once the releases are out. Because the hardfork changes consensus on L2, a new absolute prestate will be required for chains running permissionless fault proofs. The prestate quoted above encapsulates both Jovian and Fusaka readiness consensus changes.

The impact of not performing the upgrade is that the fault proof system would be broken until such a time as we can update the prestate and fix it.

Pre-commitment impact review

This Upgrade Proposal only impacts the Collective Fee Take pre-commitment in the Standard Rollup Charter.

• Collective Fee Take: while the operator fee’s offchain codepath is updated in this release, it is still required to be set to 0 for standard chains and thus does not impact the fee take today.

• Governor/Servicer Role Separation: no change to role structures or authorization patterns.

• Ossified GasLimits: no changes to ossified gasLimits

• Direct Fee Margin Controls: no change to the relevant configuration structure and authorization.

Security Considerations

We performed a Failure Mode Analysis as well as extensive end-to-end testing, including on devnets and testnets based on the live Holesky and Sepolia L1 networks which has already activated Fusaka. No audit will be performed for these changes, as the analysis linked above revealed no additional safety risks will be introduced.

Action Plan

• Alphanet and Betanet testing has been completed.

• Mainnet upgrade will be executed on 26th November.

• Mainnet activation will be scheduled for 2nd December.

The upgrade will occur automatically for chains on the Jovian releases of op-geth and op-node if those chains have opted-in to activate at Superchain times via their superchain-registry configuration (i.e., have the superchain_time set to a timestamp before or at the mainnet activation time, or have set their jovian_time directly) and are using the --network (op-node) and --op-network (op-geth) flags or corresponding environment variables or corresponding flags for kona-node and op-reth.

Chain operators running fault proof infrastructure should ensure they are running op-challenger version v1.7.0.

Key L1 Mainnet Fusaka hardfork Dates

The Fusaka network upgrade will activate on L1 Mainnet as follows:

Network	Epoch	Start Slot	UTC Time	UNIX Timestamp
L1 Mainnet	411392	13,164,544	2025-12-03 21:49:11	1764798551

Blob Parameter Only (BPO) Fork Schedule

Following the main Fusaka activation, the network will implement Blob Parameter Only forks to gradually increase blob throughput. BPO1 will increase the per-block blob target and maximum to 10 & 15 respectively. BPO2 will further increase the target to 14 and maximum to 21.

Mainnet BPO Schedule

BPO Fork	Epoch	Start Slot	UTC Time	UNIX Timestamp
BPO1	412672	13,205,504	2025-12-09 14:21:11	1765290071
BPO2	419072	13,410,304	2026-01-07 01:01:11	1767747671

Conclusion

U17 is a proposed network upgrade for OP Stack chains that addresses several key improvements:

1. Cannon update to support Go 1.24, ensuring the OP Stack remains compatible with upstream changes to go-ethereum and provides users with the latest execution-layer security.

2. Fee mechanism improvements including:

   • Minimum Base Fee

   • Data Availability Footprint Block Limit

   • Operator Fee Fix

3. Fusaka Readiness which enables OP Stack chains to continue to operate as before (they do not halt) when Fusaka activates on L1.

This upgrade is essential for maintaining security best practices; delivering improvements to the Optimism protocol’s transaction fee system which will improve the user experience and reduce risk to chain operators; alongside preparing for seamless operation as Fusaka hardfork activates on L1.

The fee improvements will allow the L2 base fee to respond more quickly to changes in block composition, reduce the need for batcher-sequencer throttling, and protect rollup operators from potential spam attacks. By approving this proposal, the Optimism Collective will therefore enable increased value to both operators and users of the protocol

We request the Collective’s approval to proceed with this upgrade according to the timeline above.

[artespraticas]

Best of success for such hard work and chain improvement!!