Skip to main content

How to Run a Reth Node

Updated on
Sep 12, 2025
Ethereum
Reth
Infrastructure
Execution Clients

8 min read

Overview​

Reth is a high-performance Ethereum execution client built in Rust by Paradigm. This guide will walk you through setting up and running a Reth node, allowing you to interact directly with the Ethereum blockchain. By the end of this tutorial, you'll have a fully synced Reth node that can serve as your gateway to Ethereum.

What You Will Learn​


  • Install and configure Reth
  • Run a full Ethereum node using Reth
  • Monitor your node's synchronization status
  • Query blockchain data using JSON-RPC methods

What You Will Need​


  • A synced consensus client (e.g., Lighthouse, Nimbus) - you'll need to follow a separate consensus client guide to set this up properly
  • Minimum system requirements
  • Linux, macOS, or Windows operating system
  • Git installed
  • Basic familiarity with command line

Note: This guide demonstrates setup using the Hoodi testnet. Hoodi is the newer testnet which has replaced Holesky. To switch to mainnet for production use, see the configuration changes outlined at the end of this guide.

What is Reth?​

Reth (Rust Ethereum) is a Ethereum execution client developed by Paradigm. Written entirely in Rust, Reth focuses on being fast, memory efficient, and developer friendly. It's designed to be modular, allowing developers to customize and extend its functionality while maintaining compatibility with Ethereum.

Before getting into the technical implementation, let's first recap what execution and consensus clients are.

What are Execution Clients?​

An execution client (formerly called "Eth1 client") is responsible for handling transactions, executing smart contracts, and managing the Ethereum state. It processes all the computational work that happens on Ethereum such as transaction processing, smart contract execution, state management, mempool management.

Execution vs Consensus Clients​

Since Ethereum's transition to Proof of Stake with "The Merge" in September 2022, running a full Ethereum node requires both an execution client and a consensus client working together. Execution clients like Reth, Geth, Nethermind, and Besu handle transaction execution and state management while also providing the JSON-RPC API that developers and applications use to interact with Ethereum. Meanwhile, consensus clients such as Nimbus, Lighthouse, Prysm, and Teku manage the Proof of Stake consensus mechanism and handle validator operations and block production.

Project Set Up​

Before proceeding, ensure you have the minimum system requirements to run a consensus and execution client. In this walk-through, we'll be showing the setup with an AWS EC2 instance with the following spec:


  • Instance type: t2.xlarge
  • Volume: 1.5 TB
  • Operating System: Amazon Linux 2023

Once your machine is set up, let's build from source and install required dependencies:

Install Dependencies​


  1. Ensure Rust is installed:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

  1. Clone the repo, navigate inside and install Reth
git clone https://github.com/paradigmxyz/reth
cd reth
cargo install --locked --path bin/reth --bin reth

Note: Building could take around ~10-15 minutes


  1. If you haven't already, create a JWT Key (this will be used for both the Reth node and consensus client (e.g., Nimbus))
openssl rand -hex 32 | tr -d "\n" > /opt/jwtsecret

Node Configurations​

Let's cover the exact configuration we'll be using in this guide and also provide additional resources to setup your own custom configuration:

reth node - Launches a Reth execution client that syncs with the network, exposes RPC endpoints, and communicates with your consensus client

--chain hoodi - Specifies the Ethereum network chain to connect to

--http - Enables the HTTP JSON-RPC server

--http.addr 0.0.0.0 - Binds the HTTP JSON-RPC server to all available network interfaces

--http.port 8545 - Port for the HTTP JSON-RPC server

--authrpc.addr 127.0.0.1 - Engine API endpoint used by the consensus client to communicate with the execution layer

--authrpc.port 8551 - Engine API port that the consensus client uses to communicate with the execution client

--authrpc.jwtsecret /opt/jwtsecret - Path to the JWT secret file for secure client communication

--full - Runs in full node mode, verifying all blocks and transactions while storing complete state data

Now that we better understand the options we'll be enabling on Reth, let's get started.

Run Reth Full Node​

Choose between running Reth manually in your terminal or as a systemd service for automatic startup and management.


Setting Up Reth via Terminal​

Now to start the Reth node, run the command below:

Note: You will need your consensus client running at this point. If you haven't set up a consensus client yet, follow our Nimbus Beacon Node guide first. Without a consensus client, Reth cannot sync properly and you will see connection warnings.

reth node \
    --chain hoodi \
    --http \
    --http.addr 0.0.0.0 \
    --http.port 8545 \
    --authrpc.addr 127.0.0.1 \
    --authrpc.port 8551 \
    --authrpc.jwtsecret /opt/jwtsecret \
    --full

You'll see the following on start up:

2025-09-08T14:49:18.579719Z  INFO Initialized tracing, debug log directory: /home/ec2-user/.cache/reth/logs/hoodi
2025-09-08T14:49:18.580599Z  INFO Starting reth version="1.6.0 (e93e1fc)"
2025-09-08T14:49:18.580646Z  INFO Opening database path="/home/ec2-user/.local/share/reth/hoodi/db"
2025-09-08T14:49:18.594352Z  INFO Launching node
2025-09-08T14:49:18.595698Z  INFO Configuration loaded path="/home/ec2-user/.local/share/reth/hoodi/reth.toml"
2025-09-08T14:49:18.599860Z  INFO Verifying storage consistency.
2025-09-08T14:49:18.616544Z  INFO Database opened
2025-09-08T14:49:18.617758Z  INFO Transaction pool initialized
2025-09-08T14:49:18.617996Z  INFO Loading saved peers file=/home/ec2-user/.local/share/reth/hoodi/known-peers.json
2025-09-08T14:49:18.652799Z  INFO P2P networking initialized enode=enode://9ec058a4e354524a13a65f68fd42409696be968c97285384b40d508e9db97e7d64c88d78b88930c99351519c5733b1ce268389fd1e76f78855288d9ee7035596@0.0.0.0:30303
2025-09-08T14:49:18.653026Z  INFO StaticFileProducer initialized
2025-09-08T14:49:18.653839Z  INFO Pruner initialized prune_config=PruneConfig { block_interval: 5, segments: PruneModes { sender_recovery: Some(Full), transaction_lookup: None, receipts: Some(Distance(10064)), account_history: Some(Distance(10064)), storage_history: Some(Distance(10064)), bodies_history: None, receipts_log_filter: ReceiptsLogPruneConfig({}) } }
2025-09-08T14:49:18.658132Z  INFO Consensus engine initialized
2025-09-08T14:49:18.658304Z  INFO Engine API handler initialized
2025-09-08T14:49:18.664589Z  INFO RPC auth server started url=127.0.0.1:8551
2025-09-08T14:49:18.664917Z  INFO RPC IPC server started path=/tmp/reth.ipc
2025-09-08T14:49:18.664969Z  INFO RPC HTTP server started url=0.0.0.0:8545
2025-09-08T14:49:18.665143Z  INFO Starting consensus engine
2025-09-08T14:49:21.658936Z  INFO Status connected_peers=0 latest_block=2372
2025-09-08T14:49:46.659153Z  INFO Status connected_peers=3 latest_block=2372
2025-09-08T14:50:11.659641Z  INFO Status connected_peers=4 latest_block=2372

It could take a day to sync. So go get some coffee, scroll X or explore our other content such as our YouTube channel and Sample App Library. You can monitor the block number your node is on via the logs. Once you see the block number close to that of tip, you can make some API calls to verify:

It could take a day to sync on Hoodi (much longer on mainnet). You can monitor the block number your node is on via the logs. Once you see the block number close to the network tip, you can make API calls to verify sync status.

Interact with JSON-RPC API​

Check sync status​

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://localhost:8545

If synced, eth_syncing returns false. If syncing, it returns an object with startingBlock, currentBlock, and highestBlock.

Check current block number​

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

Hopefully by now, your node is synced, and you're ready to make more API calls. Explore the Ethereum API Documentation here and expand the Ethereum JSON-RPC API dropdown and select a few API methods to experiment with.

Get block by hash​

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0x3f07a9c83155594c000642e7d60e8a8a00038d03e9849171a05ed0e2d47acbb3",false],"id":1}' \
  http://localhost:8545

Get logs from USDT contract​

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"address": "0xdAC17F958D2ee523a2206206994597C13D831ec7"}],"id":1}' \
  http://localhost:8545

Get account balance​

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x8D97689C9818892B700e27F316cc3E41e17fBeb9", "latest"],"id":1}' \
  http://localhost:8545

Switching to Mainnet​

This guide uses the Hoodi testnet for safe experimentation. When you're ready for production, here are the key changes needed for mainnet:


  • Change --chain hoodi to --chain mainnet (or omit since mainnet is default)
  • Ensure you have adequate storage (2TB+ SSD) and bandwidth for mainnet
  • Update your consensus client to use mainnet (e.g., --network mainnet for Nimbus)
  • Use mainnet checkpoint sync endpoints url

Alternative: Use QuickNode's Managed Infrastructure​

While running your own Reth node gives you complete control and contributes to network decentralization, it also requires significant time, resources, and ongoing maintenance. If you prefer to focus on building applications rather than managing infrastructure, QuickNode offers a reliable alternative with enterprise-grade performance and 99.9% uptime.

QuickNode's Core API provides instant access to Ethereum without waiting for sync times, serving requests from a diverse set of execution clients to ensure reliability and performance. Their global network reduces latency through worldwide node distribution, and the platform handles all the complexity of client updates, security patches, and system maintenance automatically.

For applications requiring specific client implementations or enhanced performance, QuickNode's Dedicated Clusters allow you to select your preferred execution client, including Reth. These dedicated resources provide customizable configurations and let you scale seamlessly as your application grows without worrying about infrastructure limitations.

Final Thoughts​

Well done. You've successfully set up and configured a Reth execution client. Running your own Ethereum node not only gives you direct access to the blockchain but also contributes to the network's decentralization and resilience. Remember that maintaining a node requires ongoing monitoring, updates, and system maintenance. Whether you choose to run your own infrastructure or use managed services like QuickNode, understanding how Ethereum clients work gives you valuable insight into the network's architecture. This knowledge will serve you well as you build applications or explore more advanced blockchain development.

Additional Resources​


  • Explore our Ethereum API documentation to learn more JSON-RPC methods
  • Set up monitoring and alerting for your node
  • Consider running a validator if you want to participate in consensus
  • Join the Reth community on GitHub for updates and discussions

Subscribe to our newsletter for more articles and guides on Ethereum infrastructure and development. If you have any feedback, feel free to reach out to us via X. You can always chat with us on our Discord community server, featuring some of the coolest developers you'll ever meet!

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.

Written by

Ferhat Kochan

Last updated on
Share this guide