Fusaka upgrade notice

Learn how to prepare for the the Fusaka upgrade

Preparing for L1 Fusaka upgrade

This page provides external-facing information about the Fusaka readiness upgrade for OP Stack chains. It summarizes scope, timelines, required actions, and resources for chain operators and partners. This upgrade is necessary for all OP Stack chains deriving from an L1 chain which is due to activate Fusaka (including Ethereum Mainnet and Sepolia).

This is NOT Fusaka adoption on L2. It’s a readiness upgrade to make the Optimism protocol compatible with L1 that activates the Fusaka fork. L2 adoption will happen in a future upgrade.

All of the tasks below must be performed before Fusaka activates on L1 (October 14th for Sepolia chains).

What’s included in Fusaka

Fusaka contains various breaking changes. See EIP-7607: Hardfork Meta - Fusaka for more info.

Important dates:

Ethereum Sepolia Fusaka hard fork: Tuesday, October 14th, 2025 07:36:00 UTC (affects chains posting data to Sepolia)

Ethereum Mainnet Fusaka hard fork: Expected early December 2025 (affects chains posting data to Mainnet). We will update this notice with the exact date, and new software releases, once it is confirmed

For node operators

Update your node software as soon as possible after release:

• Update op-node to v1.14.1. See the release notes for new config flags and env variables (not necessary for chains deriving from Ethereum Mainnet, Sepolia, Holesky or Hoodi.)
• Update op-geth to v1.101603.1

Ensure your L1 beacon node endpoint can serve all blobs

For operators using an external L1 Ethereum Beacon:

Before the Ethereum Fusaka hard fork, ensure your external L1 Beacon Chain RPC provider has configured their node to subscribe to all subnets. If your external L1 Beacon Chain RPC provider doesn’t subscribe to all subnets, migrate to one that does prior to these deadlines.

For operators running their own L1 Ethereum Beacon Chain Node:

If you operate your own L1 nodes, ensure also both the L1 execution and beacon nodes are upgraded and configured for the Fusaka fork (see Fusaka specs here).

Outdated L1 nodes can cause derivation failures, blob unavailability, or chain divergence after the fork.

Configure your Beacon Node with the new flag (detailed below) before the relevant Fusaka hard fork date.

L1 Beacon Chain Node flags:

• Lighthouse: --supernode
• Teku: --p2p-subscribe-all-custody-subnets-enabled
• Grandine: --subscribe-all-data-column-subnets
• Lodestar: --supernode
• Nimbus: --debug-peerdas-supernode

For chain operators

Be ready to restart your batcher with the new configuration immediately after the Fusaka fork on L1: e.g. for Sepolia this is at Unix timestamp 1760427360 (Tue Oct 14 2025 07:36:00 UTC).

Although new chains deriving from Holesky are supported, exising chains deriving from Holesky are not supported since Holesky already activated Fusaka on L1.

Update the following:

Component	Version	Notes
proxyd	v4.19.0 or greater	You need to whitelist eth_blobBaseFee rpc if using proxyd for L1 load balancing. If you use dugtrio ensure this is also updated to the latest release.
op-batcher	v1.16.0	OP_BATCHER_TXMGR_ENABLE_CELL_PROOFS: true or equivalent CLI flag needs to be set and the batcher restarted just after Fusaka activates on L1.
op-node	v1.14.1	L1 chain config must be supplied via a new flag (see the release notes). Not necessary for chains deriving from Ethereum Mainnet, Sepolia, Holesky or Hoodi.
op-geth	v1.101603.1
op-challenger	v1.6.0	L1 chain config must be supplied via a new flag (see the release notes). Not necessary for chains deriving from Ethereum Mainnet, Sepolia, Holesky or Hoodi.
kona-node	v1.1.3
kona-host	v1.1.3
kona-client	v1.1.3
op-reth	v1.8.2

Note: op-node v1.14.1 uses the new /eth/v1/beacon/blobs/ API for fetching blob data from L1 beacon nodes. If you run a proxy/load balancer in front of your beacon API, ensure it correctly forwards all query parameters.

Misconfigured proxies may cause blob fetch failures or derivation stalls after the Fusaka fork.

For Permissionless Fault Proof enabled chains

Chains running permissionless fault proofs will need to deploy new dispute game contracts with new absolute prestates. The new 64 bit version of cannon will be utilized moving forward. The Sepolia Superchain, will utilize op-program/v1.7.0-rc.3.

Optimism will complete the on-chain prestate update (including Dispute Game deployment and implementation set) on OP Sepolia, Base Sepolia, Ink Sepolia, and Uni Sepolia. However, off-chain components (op-challenger) must still be configured by operators to use the new prestate.

If you are a Permissionless FP–enabled chain not included in the list above, you must perform all steps below yourself.

1. Verify the new absolute prestate

   As of upgrade 14, the 64 bit multi-threaded version of cannon is utilized.

   The absolute prestate is generated with the op-program/v1.7.0-rc.3. You can use this new absolute prestate (0x0339db503776757491b9f3038bf6f1d37b7988a2f75e823fe2656c1352ef2f91) for chains in the superchain registry.

   You can verify this absolute prestate by running the following command in the root of the monorepo on the op-program/v1.7.0-rc.3 tag:

   make reproducible-prestate
   

2. Upload your new preimage file

   During the previous step, you also generated the preimage of the absolute prestate, which is basically the op-program serialized into a binary file. You’ll find that new file at optimism/op-program/bin/prestate-mt64.bin.gz. Rename that file to have the absolute prestate hash as the filename so it looks like 0x0339db503776757491b9f3038bf6f1d37b7988a2f75e823fe2656c1352ef2f91.bin.gz.

   Upload that file to where you’re storing your other absolute preimage files. This should be the location where you’re pointing your --cannon-prestates-url at. The op-challenger will grab this file and use it when it needs to challenge games.

3. Deploy new dispute game contracts

   You will then take the absolute prestate and deploy new FaultDisputeGame and PermissionedDisputeGame contracts with that value.

4. Update the DisputeGameFactory

   You will then need to update the DisputeGameFactory to point to the new FaultDisputeGame and PermissionedDisputeGame contracts by calling DisputeGameFactory.setImplementation.

5. Execute the upgrade

   Once your op-challenger is ready with the new preimage, you can execute the “Set Dispute Game Implementation” transaction. Please simulate and validate that the expected output prior to executing the transaction.