Skip to main content
This page explains how an OP Stack node is put together: what its components are, what each one is responsible for, and how they relate to the equivalent parts of an Ethereum node. It is background reading to build a mental model before you run a node; for the steps to actually stand one up, see the Next steps below. Every node on an OP Stack network is composed of two core software services, the Rollup Node and the Execution Client. OP Mainnet also optionally supports a third component, Legacy Geth, that can serve stateful queries for blocks and transactions created before the Bedrock Upgrade.

​
Node flow diagram

The following diagram shows how the Rollup Node, Execution Client, and Legacy Geth components work together to form a complete node running on OP Stack networks. This diagram uses the op-node implementation of the Rollup Node and shows the general architecture that applies to all execution client implementations. OP Mainnet node architecture diagram.

​
Rollup node

The Rollup Node is responsible for deriving L2 block payloads from L1 data and passing those payloads to the Execution Client. The Rollup Node can also optionally participate in a peer-to-peer network to receive blocks directly from the Sequencer before those blocks are submitted to L1. The Rollup Node is largely analogous to a consensus client in Ethereum.

​
Rollup node implementations

  • op-node is the reference implementation of the Rollup Node, written in Go and maintained by Optimism. It is the default choice for any node role and is not deprecated.
  • kona-node is the Rust implementation of the Rollup Node, built as part of the Kona project. It is in active development and should be considered experimental, so give it a role where that is acceptable.
For nodes that follow every chain in an interop dependency set, deploy the consensus layer as op-supernode, which hosts an op-node instance for each chain in one process and adds cross-chain message verification. See the supernode configuration guide for recommended settings and the op-supernode configuration reference for the flag catalogue.

​
Execution client

The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard Ethereum Engine API. The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. The Execution Client is largely analogous to an execution client in Ethereum.

​
Execution client implementations

  • op-reth is the Optimism-maintained execution client, written in Rust and built on reth. It is the primary supported execution client for OP Stack nodes. See the execution client configuration guide for a working configuration.
  • Nethermind is a third-party execution client written in C# that also supports OP Stack chains. The docs focus on Optimism-maintained software; for Nethermind specifics, see the Nethermind documentation.
op-geth has reached end-of-support (2026-05-31) and does not support the now-active Karst hardfork, so op-geth nodes can no longer follow the canonical chain. Migrate to op-reth, the primary supported execution client. See the op-geth deprecation notice for the full migration plan.
op-program has also reached end of support, replaced by kona-client for fault proofs; the same notice covers both migrations.

​
Legacy Geth

OP Mainnet blocks and transactions from before the 2023 Bedrock Upgrade can be read from any current execution client, but re-executing them (RPC calls such as eth_call against pre-Bedrock blocks) requires an optional third component, Legacy Geth (l2geth), the client that ran OP Mainnet before the upgrade. It is typically only needed for complete OP Mainnet archive nodes; see the Legacy Geth configuration guide for setup and request routing, and accessing pre-regenesis history for the even older history that predates the current chain data entirely.

​
Next steps