Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.optimism.io/llms.txt

Use this file to discover all available pages before exploring further.

Historically, every op-node in a fleet has independently derived the safe chain from L1 while also consolidating unsafe blocks received over gossip. As fleets grow and upcoming features like interop raise the cost of derivation, we highly recommend migrating to a specialized topology in which a small number of op-node instances are dedicated to L1 derivation and the rest defer to those sources. In the specialized topology, light nodes are started with --l2.follow.source pointing at a derivation source. The source is an op-node for chains without interop activation, or an op-supernode for chains in an interop dependency set (one supernode derives every chain in the set together and adds cross-chain message verification). Light nodes disable their own independent derivation and instead receive the safe chain from the source, while continuing to track the unsafe tip via gossip and the engine API.
Required for upcoming interop activation. This topology is required for node operators on OP Sepolia and Unichain Sepolia once interop activates on those chains in late June 2026 — see Prepare for interop on OP Sepolia and Unichain Sepolia for the action checklist. The corresponding mainnet activation will carry the same requirement.

​
What this means

  • Source nodes derive the full chain from L1. For chains without interop, this is a traditional op-node. For chains in an interop dependency set, it is an op-supernode, which derives every chain in the set together and verifies cross-chain messages.
  • Light nodes are op-node instances started with --l2.follow.source=<source RPC endpoint>. They stop deriving from L1 themselves and receive the safe chain from the designated source — an op-node RPC for non-interop chains, an op-supernode RPC (with the chain’s /<chainID> path prefix) for interop chains.
  • op-node is not being deprecated, and the homogeneous topology is not being removed. For chains where interop has not activated, this is a recommended operational upgrade rather than a required migration. For OP Sepolia and Unichain Sepolia, it becomes required at interop activation (see the Warning above).
  • Only the derivation role changes. Light nodes continue to serve RPC, participate in gossip, and drive their connected execution client as before.

​
Why this matters

​
L1 utilization reduction

Only the source nodes ingest L1 data for derivation. Light nodes no longer issue L1 RPC calls for the derivation pipeline, which meaningfully reduces L1 API load and provider costs for operators running many nodes.

​
Performance specialization

Light nodes shed the L1 derivation workload and can focus on advancing the unsafe chain and serving RPC, while source nodes focus exclusively on derivation.

​
Asymmetric scaling

RPC-serving capacity and derivation capacity can now be scaled independently. Operators can add or remove light nodes to match read traffic without changing L1 load, and can size the source tier separately based on derivation requirements and redundancy targets.

​
Lower cost for future rollouts

Future upgrades — including interop — will require more sophisticated derivation logic. Centralizing derivation behind a small, well-defined source tier minimizes the operational surface area affected by those upgrades and reduces the per-node cost of adopting them.

​
How to migrate

​
Node operators

Plan a migration from a homogeneous fleet of derivation-enabled op-node instances to a specialized topology:
  1. Stand up the source tier. For chains without interop, designate one or more op-node instances as sources, configured with full L1 derivation. For chains in an interop dependency set, the source tier is one or more op-supernode instances covering every chain in the set. Either way, size and monitor the source tier with redundancy for failover.
  2. Provision the remaining op-node instances as light nodes by setting --l2.follow.source=<source op-node RPC endpoint> (env: OP_NODE_L2_FOLLOW_SOURCE). Ensure light nodes can reach the source endpoint over a reliable, low-latency network path.
  3. Validate that light nodes track the safe chain correctly against the source before shifting production traffic.
  4. Update dashboards and alerting so the source tier’s health is treated as a dependency of the light-node tier.

​
Highly available topology with consensus-aware proxyd

For production deployments, we recommend placing the derivation tier behind a consensus-aware proxyd and exposing light nodes to users through a separate RPC-serving tier: Specialized op-node topology: three source op-nodes with EL (Reth) feed a consensus-aware proxyd via CL API, which fans out to two light op-nodes via --l2.follow.source
  • Deriver tier — a small, redundant set of source instances (op-node for non-interop chains, op-supernode for interop chains). These sit behind a proxyd configured with routing strategy: consensus_aware_consensus_layer, which aggregates the multiple sources into a single highly available endpoint and hides individual failures or reorgs from downstream consumers.
  • Light-node tier — a horizontally scalable pool of light op-node instances started with --l2.follow.source pointed at the deriver-tier proxyd endpoint. This tier can be scaled up and down independently based on read traffic.
  • Edge tier — an API gateway or user-facing proxyd that fronts the light-node tier and handles external RPC traffic, rate limiting, and routing.
In all cases, consider your existing topology and apply node specialization in a way that works best with your deployment stack. The goal is to have a minimal, well defined source tier (op-node or op-supernode, per chain) and a scalable collection of light nodes pointed at it.

​
Chain operators

All guidance for Node Operators is applicable to Chain Operators. For op-node instances serving as Sequencers, we suggest those nodes use --l2.follow.source to offload the work of derivation. Benchmarking indicates removing derivation eliminates some bottlenecks when producing blocks, and the role of the Sequencer is to maintain and extend the Unsafe Chain.
On chains where interop has not activated, the specialized topology is a recommendation, not a hard requirement. Existing homogeneous deployments on those chains continue to work, and migration can be done incrementally, one light node at a time.
op-node is not sufficient as a derivation source for chains in an interop dependency set — those chains use op-supernode, which derives every chain in the set together and verifies cross-chain messages. Future protocol features may impose similar requirements on other chains. Operators who keep running large fleets of derivation-enabled op-node instances on chains where the source role is changing should expect a higher operational burden: more L1 API cost today, and a per-node cost to upgrade every derivation-enabled instance as new derivation requirements land. Specializing the topology now minimizes the number of nodes affected by those changes.

​
Resources

  • Interop prep notice — node-operator action checklist for the OP Sepolia and Unichain Sepolia interop activation, where this topology is required rather than recommended.
  • --l2.follow.source flag (env: OP_NODE_L2_FOLLOW_SOURCE) — configures an op-node as a light node pointed at a source op-node RPC endpoint.
  • --l2.follow.source.rpc-timeout flag (env: OP_NODE_L2_FOLLOW_SOURCE_RPC_TIMEOUT) — tunes the RPC call timeout used when talking to the source (default 10s).