---
description: How to run Reth on Ethereum mainnet and testnets.
---

# Running Reth on Ethereum Mainnet or testnets

Reth is an [_execution client_](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients). After Ethereum's transition to Proof of Stake (aka the Merge) it became required to run a [_consensus client_](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) along with your execution client in order to sync into any "post-Merge" network. This is because the Ethereum execution layer now outsources consensus to a separate component, known as the consensus client.

Consensus clients decide what blocks are part of the chain, while execution clients only validate that transactions and blocks are valid in themselves and with respect to the world state. In other words, execution clients execute blocks and transactions and check their validity, while consensus clients determine which valid blocks should be part of the chain. Therefore, running a consensus client in parallel with the execution client is necessary to ensure synchronization and participation in the network.

By running both an execution client like Reth and a consensus client, such as Lighthouse 🦀 (which we will assume for this guide), you can effectively contribute to the Ethereum network and participate in the consensus process, even if you don't intend to run validators.

| Client    | Role                                          |
| --------- | --------------------------------------------- |
| Execution | Validates transactions and blocks             |
|           | (checks their validity and global state)      |
| Consensus | Determines which blocks are part of the chain |
|           | (makes consensus decisions)                   |

## Running the Reth Node

First, ensure that you have Reth installed by following the [installation instructions][installation].

Now, to start the archive node, run:

```bash
reth node
```

And to start the full node, run:

```bash
reth node --full
```

On differences between archive and full nodes, see [Pruning & Full Node](/run/faq/pruning#basic-concepts) section.

:::note
These commands will not open any HTTP/WS ports by default.

You can change this by adding the `--http`, `--ws` flags, respectively and using the `--http.api` and `--ws.api` flags to enable various [JSON-RPC APIs](/jsonrpc/intro).

For more commands, see the [`reth node` CLI reference](/cli/cli).
:::

The EL \<> CL communication happens over the [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md), which is by default exposed at `http://localhost:8551`. The connection is authenticated over JWT using a JWT secret which is auto-generated by Reth and placed in a file called `jwt.hex` in the data directory, which on Linux by default is `$HOME/.local/share/reth/` (`/Users/<NAME>/Library/Application Support/reth/mainnet/jwt.hex` in Mac).

You can override this path using the `--authrpc.jwtsecret` option. You MUST use the same JWT secret in BOTH Reth and the chosen Consensus Layer. If you want to override the address or port, you can use the `--authrpc.addr` and `--authrpc.port` options, respectively.

So one might do:

```bash
reth node \
    --authrpc.jwtsecret /path/to/secret \
    --authrpc.addr 127.0.0.1 \
    --authrpc.port 8551
```

At this point, our Reth node has started discovery, and even discovered some new peers. But it will not start syncing until you spin up the consensus layer!

## Running the Consensus Layer

First, make sure you have Lighthouse installed. Sigma Prime provides excellent [installation](https://lighthouse-book.sigmaprime.io/installation.html) and [node operation](https://lighthouse-book.sigmaprime.io/run_a_node.html) instructions.

Assuming you have done that, run:

```bash
lighthouse bn \
    --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
    --execution-endpoint http://localhost:8551 \
    --execution-jwt /path/to/secret
```

If you don't intend on running validators on your node you can add:

```bash
  --disable-deposit-contract-sync
```

The `--checkpoint-sync-url` argument value can be replaced with any checkpoint sync endpoint from a [community-maintained list](https://eth-clients.github.io/checkpoint-sync-endpoints/#mainnet).

Your Reth node should start receiving "fork choice updated" messages, and begin syncing the chain.

## Verify the chain is growing

You can easily verify that by inspecting the logs, and seeing that headers are arriving in Reth. Sit back now and wait for the stages to run!
In the meantime, consider setting up [observability](/run/monitoring) to monitor your node's health or [test the JSON RPC API](/jsonrpc/intro).

{/* TODO: Add more logs to help node operators debug any weird CL to EL messages! */}

[installation]: ../installation/overview
[docs]: https://github.com/paradigmxyz/reth/tree/main/docs
[metrics]: https://github.com/paradigmxyz/reth/blob/main/docs/design/metrics.md#metrics

## Running without a Consensus Layer

We provide several methods for running Reth without a Consensus Layer for testing and debugging purposes:

### Manual Chain Tip Setting

Use the `--debug.tip <HASH>` parameter to set the chain tip manually. If you provide this to your node, it will simulate sending an `engine_forkchoiceUpdated` message _once_ and will trigger syncing to the provided block hash. This is useful for testing and debugging purposes, but in order to have a node that can keep up with the tip you'll need to run a CL alongside with it.

Example, sync up to block https://etherscan.io/block/23450000:

```bash
reth node --debug.tip 0x9ba680d8479f936f84065ce94f58c5f0cc1adb128945167e0875ba41a36cd93b 
```

Note: This is a temporary flag for testing purposes. At the moment we have no plans of including a Consensus Layer implementation in Reth, and we are open to including light clients and other methods of syncing like importing Lighthouse as a library.

### Running with Etherscan as Block Source

You can use `--debug.etherscan` to run Reth with a fake consensus client that advances the chain using recent blocks on Etherscan. This requires an Etherscan API key (set via `ETHERSCAN_API_KEY` environment variable). Optionally, specify a custom API URL with `--debug.etherscan <URL>`.

Example:

```bash
export ETHERSCAN_API_KEY=your_api_key_here
reth node --debug.etherscan
```

Or with a custom Etherscan API URL:

```bash
export ETHERSCAN_API_KEY=your_api_key_here
reth node --debug.etherscan https://api.etherscan.io/api
```

### Running with RPC Consensus

Use `--debug.rpc-consensus-url` to run Reth with a fake consensus client that fetches blocks from an existing RPC endpoint. This supports both HTTP and WebSocket endpoints:

- **WebSocket endpoints**: Will use subscriptions for real-time block updates
- **HTTP endpoints**: Will poll for new blocks periodically

Example with HTTP RPC:

```bash
reth node --debug.rpc-consensus-url https://eth-mainnet.g.alchemy.com/v2/your-api-key
```

Example with WebSocket RPC:

```bash
reth node --debug.rpc-consensus-url wss://eth-mainnet.g.alchemy.com/v2/your-api-key
```

Note: The `--debug.tip`, `--debug.etherscan`, and `--debug.rpc-consensus-url` flags are mutually exclusive and cannot be used together.
