Skip to main content
The consensus client (also called the rollup node) builds, relays, and verifies the canonical chain of blocks. This guide covers configuration for the most popular consensus client implementations.
Always run your consensus client and execution client in a one-to-one configuration. Don’t run multiple execution client instances behind one consensus client, or vice versa.

Consensus clients

Choose the consensus client that best fits your needs:

op-node configuration

op-node is the reference implementation of the OP Stack consensus client, written in Go.

Minimal configuration

The minimum required flags for running op-node:
op-node \
  --l1=https://ethereum-rpc-endpoint.example.com \
  --l1.beacon=https://ethereum-beacon-endpoint.example.com \
  --l2=http://localhost:8551 \
  --l2.jwt-secret=/path/to/jwt-secret.txt \
  --network=op-mainnet \
  --rpc.addr=0.0.0.0 \
  --rpc.port=9545

Sequencer configuration

If you’re running a sequencer node, use these additional flags:
--rpc.addr=0.0.0.0 \
--rpc.port=9545 \
--rpc.enable-admin \
--sequencer.enabled \
--sequencer.l1-confs=4 \
--p2p.sequencer.key=<your-sequencer-private-key>
Keep your sequencer private key secure and never commit it to version control. Use environment variables or secure key management systems in production.

l2.enginekind

The kind of engine client, used to control the behavior of optimism in respect to different types of engine clients. Supported values are geth (default) and reth.

Complete reference

For all available configuration options, see the op-node configuration reference.

JWT secret

To communicate with execution client and enable the Engine API, you’ll also need to generate a JWT secret file and enable the consensus client’s authenticated RPC endpoint. To generate the JWT secret file:
openssl rand -hex 32 > jwt-secret.txt