op-node and kona-node on the consensus
layer, op-reth on the execution layer, and the special-purpose
op-supernode and legacy Geth. Support status changes over time; the
facts on this page are stated as of the last-reviewed date above, and
each exit links where to re-check them.
Is this guide for you?
Use this guide if:- You are choosing software for a new node on an OP Stack chain (OP Mainnet, another OP Stack chain, or your own chain), or re-evaluating an existing node after the op-geth end of support.
- You want the selection reasoning, not the setup commands.
Before you start
You should already know:- Which network the node serves, and whether it is in the superchain-registry (registry chains can be selected by name in both consensus clients; custom chains supply their own configuration).
- The job the node does: public RPC, personal verifier, sequencer, fault-proof infrastructure, or archive/analytics. Step 5 keys on this.
- Your hardware envelope. Read the system requirements and take away the 16 GB RAM baseline for OP Mainnet and that archive nodes need multiple terabytes of NVMe and grow much faster than full nodes.
Step 1: Fix the shape: one consensus client, one execution client
Every OP Stack node is two processes: a consensus client (rollup node) that derives and relays the canonical chain, and an execution client that runs the EVM and holds state, connected 1:1 over the authenticated Engine API. Read the node architecture overview and take away:- The two-client split and which RPCs live on which side; you are making two client choices, not one.
- The 1:1 rule: never multiple execution clients behind one consensus client or vice versa. Both client configuration guides (the Step 3 and Step 4 reads) open with this warning.
Step 2: Rule out end-of-support software
Read the end-of-support notice and take away, as of 2026-07-21:- op-geth reached end of support on 2026-05-31 and does not support the now-active Karst hardfork, so op-geth nodes can no longer follow the canonical chain. It is not a candidate for any new node.
- op-program has also reached end of support, replaced by kona-client for fault proofs. This affects Step 5’s fault-proof row, not your ordinary node choice.
- op-node is not deprecated, and kona-node is not required for anything: the fault-proof migration to kona-client works with an ordinary op-node.
Step 3: Choose the execution client
Read the execution client configuration guide and take away each client’s minimal configuration and where its full reference lives. The selection logic:
Third-party execution clients maintained outside Optimism also exist, such
as Nethermind; they are configured and supported through their own
documentation, not these docs.
Two op-reth follow-on decisions to make now rather than after sync:
- Archive or full: op-reth is an archive node by default; pass
--fullfor a pruned full node. Body pruning is unsupported. See pruning op-reth. - Historical proofs: infrastructure that serves withdrawal proving on permissionless fault-proof chains needs the historical-proofs store (op-reth v2.2.3 or later); follow the historical proofs tutorial. The store only fills forward from the moment you enable it, so a node that turns it on late cannot serve the full retention window until it has run that long; decide per node role in Step 5.
Step 4: Choose the consensus client
Read the consensus client configuration guide and take away each client’s minimal flags and sequencer additions. The selection logic:
One pairing note: op-node’s
--l2.enginekind flag tunes its Engine API
behavior to the execution client, and its default is reth, so the Step 3
default needs no extra flag; the
consensus client guide
covers the other values.
Step 5: Match the pairing to the node’s job
The connective logic across both choices, by node role:Step 6: Deploy and verify the choice
Stand the pair up with the Docker node tutorial (op-reth + op-node in one compose file) or the from-source tutorial, then confirm the choice behaves like the row you picked:- Versions: the running versions match the latest stable releases on the releases page; the page is regenerated from the release feed, so it is the freshness check for this guide’s dated claims.
- Sync:
optimism_syncStatuson the consensus client (see the op-node JSON-RPC reference) shows the unsafe head tracking the chain head you see on a public explorer, and the execution client reports sync complete. - Disk shape: an archive node’s disk grows like an archive node’s; if you meant to run full and the datadir is heading toward terabytes, revisit the pruning flags from Step 3 before the disk fills.
- Role checks: whatever Step 5 row you picked, exercise its defining
feature once: a historical state query on an archive node, a
debug-namespace proof call on challenger infrastructure, or a cross-chain message check on a supernode.
Next steps
- op-node configuration reference: the full flag catalogue, generated from the op-node flag definitions at the release tag named on the page and regenerated when a new finalized release is published.
- op-reth configuration reference: routes to the imported op-reth CLI reference (versioned with the op-reth source tree) and the historical-proofs configuration pages.
- kona-node documentation: the install-and-run book for the Rust consensus client, in the Node Operators section of these docs.
- Consensus-layer sync: why execution-layer (snap) sync is the recommended mode and what consensus-layer sync is for, when you tune how the pair syncs.
- reth.rs OP Stack chapter: upstream op-reth operational documentation. External book maintained with reth releases, as of 2026-07-21.