Always run your execution client and consensus client in a 1:1 configuration. Don’t run multiple execution clients behind one consensus client, or vice versa.
What a running node needs
The execution client is one of three pieces. Before configuring it, make sure you have:- L1 endpoints for the settlement layer of the chain you are syncing: an L1 execution RPC endpoint and an L1 Beacon API endpoint. Your consensus client reads batch data and blobs from them.
- A consensus client, also called the rollup node: op-node or kona-node. It derives the canonical chain from L1 and drives the execution client over the Engine API. See Consensus client configuration.
- An execution client, configured below.
Execution clients
- op-reth
- Nethermind
op-reth is a Rust-based execution client and the primary supported path for OP Stack nodes going forward. The Superchain Registry chain configurations are compiled into the binary, so registry chains work by name through
--chain (for example --chain unichain or --chain unichain-sepolia).Install
Two supported install paths:- Docker image, wired up end to end in Running a Node With Docker.
- From source. op-reth lives at
rust/op-reth/inside the Optimism monorepo and builds with Cargo. Follow Building and running an OP Stack node from source, which pins op-node and op-reth to the same coordinated release tag.
Minimal configuration
OP Stack specific flags
op-reth’sRollup flag group holds the behavior that exists only on OP Stack chains. Two matter to most operators:--rollup.sequencer <uri>(shown above) is the sequencer endpoint that transactions submitted to this node are forwarded to, since the sequencer is what builds blocks. Aliases:--rollup.sequencer-http,--rollup.sequencer-ws.--rollup.disable-tx-pool-gossipstops the node from gossiping its transaction pool to peers. Omit it on a personal node; set it on a replica you operate as a provider.
op-reth node flag listing, and Understanding the op-reth CLI for how the flag groups fit together.Historical proofs
Permissionless chains need ~28 days of historical state for withdrawal proving. Follow the Running op-reth with Historical Proofs tutorial to set up the--proofs-history (v2) store on op-reth v2.2.3 or later.Pruning
op-reth defaults to an archive node. To reclaim disk, prune the state and receipt segments and keep block bodies. Body pruning (--minimal or --prune.bodies.distance) is unsupported and advised against. See Pruning op-reth.Complete reference
JWT secret
The execution client and consensus client communicate over the Engine API using a shared JWT secret:op-geth (legacy, end of support 2026-05-31)
op-geth configuration (legacy)
op-geth configuration (legacy)
op-geth is a minimal fork of go-ethereum optimized for the OP Stack.Defaults: snap sync mode, no WebSocket server, no metrics.
Although the Docker image is called
op-geth, the actual binary is still named geth to minimize differences from go-ethereum. See the op-geth diff viewer for details.Minimal configuration
OP Stack specific flags
--rollup.sequencerhttp: HTTP endpoint of the sequencer for transaction submission--rollup.disabletxpoolgossip: Disables transaction pool gossip (for replica nodes)--rollup.historicalrpc: Enables historical RPC endpoint for upgraded networks (OP Mainnet pre-bedrock archive nodes)