Reth Ethereum Execution Client: Architecture, Node Setup, and RPC Operations

What Reth Is and Where It Fits

Reth (short for Rust Ethereum) is an Ethereum execution layer client. It is responsible for transaction execution, state storage, the EVM, and the JSON-RPC surface that applications query. It is not a consensus client: it must be paired with a beacon/consensus client such as those implementing the Engine API, which handles fork choice, validator duties, and block gossip.

The project is developed in the open by Paradigm and a broad contributor base, and is distributed under the Apache/MIT license. Its stated design goals are modularity, performance, and contributor friendliness. Because the codebase is organized as separate crates, the same components can be assembled into a standard Ethereum full node, an archive node, or a customized EVM-compatible chain.

One naming caution before going further: the token ticker "rETH" (Rocket Pool ETH) is unrelated to the Reth client. If you arrived looking for a liquid staking token price, this is not that topic. Everything below concerns the node software.

• Execution client: executes transactions, maintains state, serves JSON-RPC.
• Requires a consensus client connected over the Engine API.
• Supports full and archive modes depending on pruning configuration.
• Modular crates allow custom nodes and execution extensions (ExEx).

Assumptions and Prerequisites

This guide assumes you have administrative access to a Linux host, a basic understanding of Ethereum's execution/consensus split, and a consensus client already installed or ready to install. It also assumes you are comfortable with systemd, firewall rules, and reading logs.

Hardware requirements vary by mode. A full node needs substantially more disk than a light client and benefits from fast NVMe storage; an archive node needs considerably more. Rather than quoting fixed figures that change with chain growth and client releases, check the current requirements in the official Reth documentation before provisioning, then size storage with headroom for growth. Memory and CPU should be sized for your RPC workload, not just for syncing.

• A consensus client (beacon node) with Engine API support.
• A JWT secret shared between execution and consensus clients.
• Persistent, fast local disk; avoid network-attached storage for the database.
• Outbound internet access for peer discovery and snap sync.

The Modular Architecture in Mental-Model Form

Think of Reth as a pipeline with replaceable stages. Networking and block download feed a staged sync pipeline that executes blocks and writes state. A storage layer persists headers, bodies, receipts, and state. On top sits the RPC server, which reads from that storage and can be extended.

The staged sync design is the key operational concept. Instead of executing every block in strict sequence from genesis in one pass, Reth processes the chain in stages (headers, bodies, senders, execution, and so on), each of which can be resumed. This is why sync progress is reported per stage and why a restart generally resumes rather than restarts. When you diagnose a slow or stalled sync, you are usually diagnosing one stage.

The execution extension mechanism (ExEx) lets you subscribe to committed blocks and run custom logic in-process, which is useful for indexers and off-chain services. For most operators, though, the practical surface is the CLI, the configuration file, and the RPC API.

Installing Reth and Preparing the Host

Install through your package manager where a formula exists, or build from source if you need a specific commit. The commands below use placeholders; substitute your own data directory and JWT path.

Create a dedicated service user, a data directory, and a JWT secret. The JWT secret must be identical for the execution and consensus clients, and it should be readable only by those services.

# Example host preparation (adjust paths and user to your environment)
sudo useradd --system --home /var/lib/reth reth
sudo mkdir -p /var/lib/reth/data /var/lib/reth/jwt
sudo openssl rand -hex 32 | sudo tee /var/lib/reth/jwt/jwt.hex > /dev/null
sudo chown -R reth:reth /var/lib/reth
sudo chmod 600 /var/lib/reth/jwt/jwt.hex

# Install via Homebrew on macOS/Linux where available
brew install paradigmxyz/brew/reth

# Or build from source
# git clone https://github.com/paradigmxyz/reth && cd reth
# cargo build --release --locked

Running a Node with JSON-RPC Enabled

Start Reth with an explicit data directory, the Engine API enabled for your consensus client, and only the RPC namespaces you actually need. Exposing eth, net, and web3 is typical for application backends; debug and trace are expensive and should be enabled deliberately.

Bind the HTTP server to localhost by default and place a reverse proxy in front of it if remote access is required. The example below keeps the RPC local and points the Engine API at the consensus client's authenticated port.

reth node \
  --datadir /var/lib/reth/data \
  --authrpc.addr 127.0.0.1 \
  --authrpc.port 8551 \
  --authrpc.jwtsecret /var/lib/reth/jwt/jwt.hex \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3 \
  --metrics 127.0.0.1:9001

Verifying the Node Is Healthy

Verification has three layers: the process is running, the execution client is following the head, and the RPC answers correctly. Check logs first for Engine API authentication errors, which usually mean the JWT secret does not match the consensus client's copy.

Then query the RPC. A synced node returns a recent block number that advances over time, and eth_syncing returns false. Compare the reported head against a public block explorer to confirm you are not silently lagging.

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_syncing","params":[]}'

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"web3_clientVersion","params":[]}'

A Reproducible Measurement Procedure for Sync and RPC

Published performance claims are only meaningful relative to hardware, peers, and workload. Rather than trusting a number from a blog post, measure on your own host and record the conditions. The procedure below produces a results table you can compare across configurations.

First, record the environment: CPU model, RAM, disk type, kernel version, Reth version, consensus client version, and peer count. Second, measure sync by sampling the block number at fixed intervals from a clean database and computing blocks per minute per stage. Third, measure RPC latency by issuing a fixed batch of read-only calls (for example eth_blockNumber, eth_getBlockByNumber, and eth_getBalance for a fixed address) and recording p50 and p95 over at least a few hundred samples. Fourth, repeat after any configuration change.

Record results in a table like the one below. Leave the cells to be filled with your measured values; do not copy numbers from elsewhere.

• | Metric | Configuration A | Configuration B |
• | Sync blocks/min (execution stage) | measured | measured |
• | Time to head from clean DB | measured | measured |
• | RPC p50 latency (ms) | measured | measured |
• | RPC p95 latency (ms) | measured | measured |
• | Peak RSS (GB) | measured | measured |
• | Disk used after sync (GB) | measured | measured |

Exposing RPC to Applications Safely

A node that serves your own applications should not be the same surface as a public endpoint. Keep the RPC bound to localhost, terminate TLS at a reverse proxy, add authentication or IP allowlisting, and rate-limit per client. Disable namespaces you do not need; debug and trace can be used to exhaust memory and CPU.

If you would rather not operate the node yourself, a managed endpoint removes the sync, upgrade, and failover burden. OnFinality's RPC API service provides multi-chain endpoints, and you can compare plans on the RPC pricing page. For teams that need isolated capacity, a dedicated node is the relevant option. If you are still choosing a provider, the RPC Assistant's guide to the best Ethereum RPC API covers selection criteria.

// Minimal client-side health check against your own RPC_URL
const RPC_URL = process.env.RPC_URL; // e.g. http://127.0.0.1:8545

async function head() {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_blockNumber', params: [] }),
  });
  const { result } = await res.json();
  return parseInt(result, 16);
}

const a = await head();
await new Promise((r) => setTimeout(r, 15000));
const b = await head();
console.log({ start: a, end: b, advanced: b - a });

Troubleshooting Common Reth Problems

Most operational issues fall into a small set of categories. Work through them in order rather than changing several variables at once.

Engine API authentication failures. The execution and consensus clients must share the same JWT secret file. Confirm both point at the same path and that permissions allow both services to read it.

Sync appears stalled. Check which stage is active in the logs. A stalled execution stage often indicates disk saturation or insufficient memory; a stalled download stage points to peer or network issues. Restarting resumes from the last committed stage, so avoid wiping the database as a first response.

RPC timeouts under load. Confirm you have not enabled heavy namespaces, check whether the reverse proxy has a shorter timeout than the client, and measure p95 latency before and after changes. If the node is CPU-bound, adding replicas behind a load balancer is usually better than tuning a single instance indefinitely.

Disk filling unexpectedly. Archive mode and long retention of receipts and state grow steadily. Monitor disk usage as a first-class metric and alert well before capacity.

Limitations and Tradeoffs

Reth is a full execution client, not a turnkey RPC product. You still own upgrades, monitoring, backups, and incident response. Its performance characteristics depend heavily on storage and memory, so a fast client on slow disks will not deliver the throughput you expect.

Running your own node gives you data sovereignty, custom namespaces, and the ability to extend behavior in-process. Managed endpoints trade some of that control for operational simplicity and elastic capacity. Neither is universally correct; the decision depends on query volume, compliance requirements, and how much engineering time you can dedicate to node operations.

Finally, client diversity matters for the network as a whole. Running Reth alongside other execution clients in different environments reduces correlated failure risk, and it is a reason many infrastructure teams deliberately mix clients rather than standardizing on one.

Next Steps

Once your node is synced and verified, the next work is operational hardening: systemd unit with restart policy, log rotation, Prometheus scraping of the metrics endpoint, alerting on head lag and disk usage, and a documented upgrade procedure. If you plan to serve multiple applications, put a caching and rate-limiting layer in front of the RPC.

For teams expanding beyond Ethereum, review the available networks and the broader blockchain node hosting guide before deciding what to self-host. If you want a concrete endpoint recommendation rather than a build-it-yourself path, the RPC Assistant can shortlist providers; this page deliberately stops at methodology.