Prepare for interop on OP Mainnet and Unichain

Node operator action checklist for the Lagoon interop activation on OP Sepolia and Unichain Sepolia (December 3, 2026) and OP Mainnet and Unichain (December 15, 2026).

OP Stack interop is targeted to activate on OP Sepolia (chain ID 11155420) and Unichain Sepolia (chain ID 1301) on December 3, 2026, and on OP Mainnet (chain ID 10) and Unichain (chain ID 130) on Janurary 11, 2027, pending governance approval. Each pair forms a two-chain interop dependency set; run this checklist on testnet before mainnet. Interop ships in the Lagoon hardfork, which also carries post-execution transactions and sequencer-defined metering. Node operators on either chain must change their topology before the activation timestamp: each operator runs one or more op-supernode instances that derive both chains and validate the cross-chain messages between them, and the rest of the fleet runs as Light CLs, consensus-layer clients that follow the supernode instead of deriving from L1 themselves.

A node that has not been migrated to the supernode-plus-Light-CL topology by the activation timestamp cannot verify cross-chain dependencies. Every op-node in the fleet must run with --l2.follow.source (env: OP_NODE_L2_FOLLOW_SOURCE) pointed at an op-supernode that derives both chains. Without that wiring (flag unset, or pointed at a non-supernode source), the op-node’s safe head advances past the activation block without cross-chain validation, so the node cannot serve as a verifier or RPC source for the interop chain. The Specialized op-node topology notice describes the pattern in detail. Start with that notice if your fleet hasn’t moved off the homogeneous topology yet.

The activation timestamps are targeted for December 3, 2026 on OP Sepolia and Unichain Sepolia and December 15, 2026 on OP Mainnet and Unichain; the exact timestamps are not yet set. They will be published in the superchain-registry, and this page will be updated once they are pinned. The mainnet activation is subject to governance approval.

What’s changing

At the activation timestamp, OP Sepolia and Unichain Sepolia form a two-chain dependency set on testnet, and OP Mainnet and Unichain do the same on mainnet. Every block on either chain can contain executing messages that reference initiating messages on the other; a block is only safe once every initiating message it depends on has itself reached the same safety level. The work of tracking both chains and proving those dependencies moves to a new component, op-supernode, that runs every chain in the dependency set together as virtual nodes inside one process. The rest of the operator’s fleet stops deriving locally and follows the supernode’s safe view through op-node’s Light CL mode.

For how cross-chain messages and block safety work under interop, see the interop explainer.

Who this affects

This notice applies to anyone running OP Sepolia or Unichain Sepolia nodes after the testnet activation, and to anyone running OP Mainnet or Unichain nodes after the mainnet activation timestamp.

Every op-node in the fleet, whether a replica, an RPC node, or any other op-node deployment, must run as a Light CL pointed at an op-supernode that derives both chains. Each operator stands up at least one op-supernode for the dependency set and reconfigures every op-node in their fleet to follow it. If you run only one of the two chains today, you now run both: the supernode needs an execution client for each chain in the dependency set, so plan the second chain’s execution client and its sync time into the migration.

This rollout is scoped to OP Mainnet and Unichain, with OP Sepolia and Unichain Sepolia as the testnet pair. Other OP Stack chains activate the same Lagoon hardfork on their own schedule, set in their chain config in the superchain-registry, and still need the Lagoon-aware releases by their own timestamp. A chain with no dependencies gets a dependency set containing only itself, so there is nothing to cross-validate and those operators can keep running plain op-node. Other OP Stack chains move to the supernode topology only when they join an interop set.

Required components

Update or install the following components before the activation timestamp. The versions below are the current minimums for standing up the topology; the activation releases, which carry the Lagoon timestamps, will be pinned in this notice once they are cut. Expect two upgrades: migrate the topology on these versions now, then move every component to its activation release once it is pinned here, before your network’s activation timestamp. A binary that does not carry the timestamp diverges from the chain at activation and must be resynced; see Network upgrades.

Component	Version	Role
op-supernode	v1.0.6 or later	Runs OP Mainnet and Unichain (or OP Sepolia and Unichain Sepolia) as virtual nodes inside one binary and verifies cross-chain messages. Required component. See the supernode explainer and configuration guide.
op-node	v1.19.11 or later	Runs as a Light CL on every node in the fleet; safe and finalized views are inherited from the supernode.
op-reth	v2.6.1 or later	Required execution client. Run one per chain in the dependency set — an execution client cannot back two chains (op-node rejects a mismatched chain ID at startup), so a host serving both chains runs at least two execution-client processes.

The Lagoon activation timestamp and the dependency set are read from the superchain-registry bundle embedded in each release. With --network on op-node and --vn.<chainID>.network on op-supernode no extra flag is needed, which is also why the activation releases matter: a binary built before the registry update does not know the timestamp. The dependency set is looked up by chain ID, so it also applies when you pass a custom rollup config; a custom rollup config must set lagoon_time itself. To override the registry’s dependency set, pass --interop.dependency-set to op-node or --dependency-set to op-supernode.

op-supernode has shipped stable releases since v1.0.0 (August 2026); run v1.0.6 or later today. The activation releases for op-supernode, op-node, and op-reth will be pinned here once they are cut. Until then, track the op-supernode, op-node, and op-reth release pages.

Action checklist

The migration has four phases. Complete each one on OP Sepolia and Unichain Sepolia first, then repeat it on mainnet before the mainnet activation timestamp. Start the execution clients first, then the supernode — the supernode drives the execution clients (ELs) through their sync, because an EL has no way to know what chain head to target on its own. Light CLs come last, since they follow the supernode. Full per-flag reference for the supernode is in the op-supernode configuration reference; this notice walks through both setups.

The command examples in the steps are minimum viable configurations; they cover the flags required for the interop topology and nothing else. Layer your usual production flags (monitoring, logging, P2P tuning, RPC modules, resource limits) on top as your environment requires.

Each command block has a Sepolia tab and a Mainnet tab; pick the one for the network you are preparing. Sepolia commands use Sepolia L1 and beacon endpoints; mainnet commands use Ethereum mainnet endpoints. op-node and op-reth spell the same network differently; use each value exactly as shown.

1. Stand up execution clients for both chains

   Run at least one op-reth process per chain in the pair: OP Sepolia and Unichain Sepolia on testnet, OP Mainnet and Unichain on mainnet. Execution clients are not shared across chains. For each chain, plan one EL per consensus client connecting to it — one per supernode virtual node, plus one per Light CL in your fleet. Each execution client needs its own JWT secret file (a single file shared across both ELs is fine; see the note at the end of this step) and its own engine-API listen address. ELs can start unsynced; they wait until the supernode connects before they know what chain head to sync to. The supernode then drives each EL through its initial sync via the engine API, and tolerates the common case where one chain’s EL is already synced and the other isn’t. Configure each EL’s history retention so the supernode can backfill initiating-message logs after restarts or downtime; the EL retention recommendation in the supernode guide covers the retention window, the relevant op-reth pruning flags, and the extra requirements that apply if you also run op-challenger.

   Sepolia

   # OP Sepolia execution client
   op-reth node \
     --chain=optimism-sepolia \
     --datadir=/var/lib/op-reth-op-sepolia \
     --authrpc.addr=127.0.0.1 \
     --authrpc.port=8551 \
     --authrpc.jwtsecret=/etc/op/jwt-secret.txt
   
   # Unichain Sepolia execution client
   op-reth node \
     --chain=unichain-sepolia \
     --datadir=/var/lib/op-reth-unichain-sepolia \
     --authrpc.addr=127.0.0.1 \
     --authrpc.port=8561 \
     --authrpc.jwtsecret=/etc/op/jwt-secret.txt
   

   The examples bind the engine RPC to 127.0.0.1. If op-reth runs in a Docker container, or on a different host from the supernode, set --authrpc.addr=0.0.0.0 (or a specific interface IP reachable from the supernode) and restrict access at the network layer.

   Each EL in the fleet has exactly one consensus client connected to it. The supernode drives its ELs via per-chain virtual nodes; each Light CL also gets its own EL. The supernode can share one JWT secret path across all of its virtual nodes, with per-chain overrides if an EL needs its own secret; the shared JWT secret recommendation in the supernode guide covers the flags. Each Light CL connects to its EL with its own --l2.jwt-secret flag.

2. Stand up op-supernode for both chains

   Run op-supernode with both chains in --chains (11155420,1301 on testnet, 10,130 on mainnet), the matching --vn.<chainID>.network values (op-sepolia and unichain-sepolia, or op-mainnet and unichain-mainnet), a shared L1 RPC for that pair’s L1, and a shared beacon endpoint. The example configuration in the supernode guide is written for exactly this dependency set (OP Mainnet plus Unichain); use it as your starting point, and keep the engine kind set to reth for both chains since the fleet runs op-reth. Follow the guide’s recommendation to configure a beacon archiver fallback from the start, so a supernode that has been offline for an extended period can still recover pruned blobs.

   For the full flag reference, see the op-supernode configuration reference; for recommendations, see the supernode configuration guide.

3. Migrate every op-node in the fleet to Light CL

   On every op-node, set --l2.follow.source to your op-supernode’s per-chain RPC endpoint (the /<chainID> path prefix). This disables local derivation; the op-node becomes a Light CL and inherits its safe and finalized view from the supernode.

   Sepolia

   # OP Sepolia verifier / RPC op-node
   op-node \
     --network=op-sepolia \
     --l1=<your-sepolia-l1-eth-rpc> \
     --l1.beacon=<your-sepolia-l1-beacon-rpc> \
     --l2=http://op-sepolia-reth:8551 \
     --l2.jwt-secret=/etc/op/jwt-secret.txt \
     --l2.follow.source=http://op-supernode:8545/11155420 \
     --rpc.addr=0.0.0.0 \
     --rpc.port=9545
   
   # Unichain Sepolia verifier / RPC op-node
   op-node \
     --network=unichain-sepolia \
     --l1=<your-sepolia-l1-eth-rpc> \
     --l1.beacon=<your-sepolia-l1-beacon-rpc> \
     --l2=http://unichain-sepolia-reth:8561 \
     --l2.jwt-secret=/etc/op/jwt-secret.txt \
     --l2.follow.source=http://op-supernode:8545/1301 \
     --rpc.addr=0.0.0.0 \
     --rpc.port=9546
   

   --l1 and --l1.beacon are still required at startup even in Light CL mode — op-node rejects the configuration without them. The Light CL stops issuing L1 RPC calls for derivation work itself; it still keeps L1 references open for runtime config updates and engine-API book-keeping. Unsafe-head progression over P2P is unchanged.

   For background on the topology and why it scales, see the specialized op-node topology notice.

4. Plan the production topology before activation

   For production fleets, run several supernodes as a highly available pool behind a consensus-aware proxyd and point the Light CLs at the pool rather than at a single supernode; a lone supernode is fine for evaluating the setup, but it is a single point of failure for safe-head progression on both chains. Put this in place before the activation timestamp: the HA pool recommendation in the supernode guide covers the pool size, routing strategy, and failure behavior.

Verify your setup before activation

Run these checks against your topology before the activation timestamp. None of them require interop to be active on either chain; they exercise the supernode-plus-Light-CL plumbing on its own so the activation block does not surface configuration errors for the first time.

Confirm the supernode is hosting both chains

Watch the supernode’s logs using whatever you already use (docker logs -f op-supernode, journalctl -fu op-supernode, kubectl logs -f op-supernode, etc.). Each chain container tags its log lines with its chain_id, so a healthy supernode produces interleaved derivation lines for both chains. The most common line during catch-up is "Advancing bq origin" (the batch-queue is walking forward through L1):

Sepolia

t=2026-11-20T12:00:00+0000 lvl=info msg="Advancing bq origin" chain_id=11155420 vn_id=7754 origin=0x...:12500000 originBehind=false
t=2026-11-20T12:00:00+0000 lvl=info msg="Advancing bq origin" chain_id=1301     vn_id=d5ca origin=0x...:12500000 originBehind=false

Both chain IDs of your pair (11155420 and 1301 on testnet, 10 and 130 on mainnet) should appear regularly. Block numbers in the sample lines are illustrative. If you only see one chain, the other’s container failed to start or its execution client is unreachable — error-level lines tagged with the missing chain explain why. Once the supernode catches up and starts promoting heads, you will also see msg="Sync progress" lines with l2_safe, l2_unsafe, and l2_finalized fields tagged with the same chain_id.

If you have Prometheus scraping the supernode, the gauge op_node_supernode_refs_number{layer="l2",type="l2_safe"} carries the per-chain safe head on the virtual_node_chain_id label — a single Grafana panel makes the per-chain progression continuously visible.

Confirm a Light CL is following the supernode

Watch a Light CL’s logs the same way and look for "Follow Source: Process external refs" and "Follow Upstream" lines. A working Light CL produces these continuously while it polls the supernode’s optimism_syncStatus:

Sepolia

t=2026-11-20T12:00:00+0000 lvl=info msg="Safety levels" unsafe=enabled safe=http://op-supernode:8545/11155420
t=2026-11-20T12:00:00+0000 lvl=info msg="Follow Upstream" eSafe=0x...:40000000 eLocalSafe=0x...:40000000 eFinalized=0x...:39999900 eCurrentL1=0x...:12500200
t=2026-11-20T12:00:00+0000 lvl=info msg="Follow Source: Process external refs" externalSafe=0x...:40000000 externalLocalSafe=0x...:40000000 externalFinalized=0x...:39999900

The first "Safety levels" line is the smoke test: if safe= shows your supernode URL and per-chain prefix, the wiring is right; the block numbers are illustrative. Once the supernode is past initial sync and starts promoting safe heads, eSafe and externalSafe carry climbing block numbers. If the Light CL never advances past genesis (eSafe=...:0) for many minutes, --l2.follow.source is pointed at the wrong URL or namespace — recheck the per-chain prefix (/11155420 for OP Sepolia, /1301 for Unichain Sepolia; /10 and /130 on mainnet).

If you scrape Prometheus, the equivalent gauge on a Light CL is op_node_default_refs_number{layer="l2",type="l2_safe"} — one Grafana panel per Light CL plus one panel per supernode chain, side by side, makes any divergence obvious.

Troubleshooting

• Safe head advances but RPC consumers report invalid blocks. The op-node isn’t following an op-supernode (--l2.follow.source is unset, or it points at a non-supernode source), so safe-head promotion skips cross-chain validation. Point --l2.follow.source at a supernode that derives both chains.
• Blobs missing for L1 blocks older than ~18 days. The primary beacon node has pruned them. Configure --l1.beacon-fallbacks against a non-pruning beacon or an archiver service. See the blob archiver guide for options.
• Light CL safe head lags the supernode by more than a few blocks. Check the network path between Light CL and supernode (or supernode proxyd). The Light CL polls optimism_syncStatus over RPC; a high-latency or rate-limited path here directly delays safe-head propagation.

Resources

• Interop explainer — how cross-chain messages and block safety work under interop.
• op-supernode explainer — what op-supernode is, why it exists, and how it pairs with Light CL.
• Supernode configuration guide — recommended settings and starter configuration.
• op-supernode configuration reference — full flag and environment-variable catalogue.
• Specialized op-node topology notice — operator-facing pattern for running Light CL fleets behind a safe source.
• Interop reorg awareness — how the safety model handles equivocation and L1 reorgs.
• Cross-chain security measures — how the safety level for inbound cross-chain messages is configured at the chain level.
• Running op-reth with Historical Proofs — only relevant if you also run op-challenger; configures the supernode’s ELs to serve historical proofs.