# Reth: A Rust Ethereum Execution Client You Can Also Use as a Library

> Reth is Paradigm's Apache/MIT-licensed Ethereum execution layer client, written in Rust and split into crates you can import individually. Here is how it installs, what Storage V2 changes, and where it is the wrong choice.

**paradigmxyz/reth** — Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, in Rust

- Repository: https://github.com/paradigmxyz/reth
- Website: https://reth.rs/
- Stars: 5,802 · Forks: 2,555
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/paradigmxyz-reth

## What Reth Is For, and Who Actually Needs It

Reth is an Ethereum execution layer client. That places it in a specific slot: it executes transactions and maintains state, and it talks to a consensus layer client over the Engine API. The README states that Reth is compatible with all Ethereum consensus layer implementations that support that API, which means you still need a separate CL client such as a beacon node. Reth is not a full node in the sense of doing both jobs.

The project's stated goals explain the intended audience better than the feature list does. Modularity comes first: every component is built to be used as a library, well tested and documented, so you can import crates and mix them. That is an unusual pitch for an execution client. Most node software is a binary you run. Reth is also a set of Rust crates, and the examples directory in the repository reflects that: custom-evm, custom-node-components, custom-payload-builder, custom-rpc-middleware, exex-subscription, and roughly twenty more. If you are building an EVM chain or an indexing service that needs execution semantics, those examples are the entry point.

The second audience is node operators. The README recommends that professional node operators switch to Reth in production for performance and cost reasons in cases where high performance with great margins is required, and names RPC, MEV, indexing, simulations and P2P activity. The third audience is contributors. The repository carries CONTRIBUTING.md, a docs directory, and a project layout document aimed at people who want to work on the client itself. Those three groups need different things from the same repository, and the documentation is organized around that split.

## Crates, the Engine API, and Storage V2

The workspace layout is the clearest description of the architecture. Cargo.toml lists members grouped by concern: crates/consensus, crates/engine, crates/evm, crates/net, crates/storage, crates/exex, crates/ethereum, crates/cli. Networking is itself split into discv4, discv5, dns, ecies, eth-wire, nat and p2p crates. The engine directory splits into tree, primitives, execution-cache and util. This is not a monolith with a plugin hook; it is a dependency graph you can enter at any level.

The EVM is revm, and the README notes that revm was audited by Guido Vranken. Alloy provides the Ethereum types. Data flows the way you would expect from an execution client: the network layer receives blocks and transactions, the engine crate drives the execution tree and payload building, the EVM crate executes, and the storage crates persist. The exex crates are the extension point for downstream consumers that want to subscribe to execution events rather than poll an RPC endpoint.

The storage change is the part operators should read carefully. Storage V2 is the default for new nodes in Reth 2.0. Existing V1 nodes continue to work, but the README states plainly that V1 support will be removed in a future release and that all users are encouraged to migrate. This is not a cosmetic difference. The beta release notes describe the earlier database model change as providing faster query speed, a smaller database footprint, and the ability to mount history on separate drives. V2 snapshots are published at snapshots.reth.rs, which is the practical migration path for anyone who does not want to re-sync from genesis. Treat the V1 to V2 move as a scheduled task with a deadline you do not control, not as an optional optimization.

## Installing Reth and Running a First Node

The README points to the installation documentation at reth.rs for how to install and run Reth, and to a separate build-from-source page. The Makefile in the repository defines an install target that builds and installs the binary under the Cargo home directory. The command below is that target's underlying cargo invocation, with the profile and features variables left at their defaults.

```bash
cargo install --path bin/reth --bin reth --force --locked --profile release
```

Expect a long compile. The Dockerfile builds with a maxperf profile by default and applies platform-specific RUSTFLAGS on linux/amd64, which tells you the maintainers consider compiler flags part of the performance story. If you would rather not build, the Dockerfile and docker-bake.hcl in the repository are the container path.

For development work, the README gives the clone and test sequence. Note that the MSRV is 1.95, so an older toolchain will fail before it reaches any project code.

```bash
git clone https://github.com/paradigmxyz/reth
cd reth
cargo nextest run --workspace
make ef-tests
```

The README recommends cargo nextest over cargo test, noting that cargo test is not tested and does not support retries for spurious failures. It also warns that some tests use random number generators for test data, and that setting the SEED environment variable makes the seed deterministic. To run the full test suite you need Geth installed; a subset runs without it.

Once the binary exists, the README does not give a run command in the documentation available here. It directs users to reth.rs for running instructions, so check the user documentation for the exact flags and for the Engine API endpoint your consensus client will connect to. Do not guess at flags: this client's CLI is large and versioned.

## Where Reth Is the Wrong Tool

The first limitation is the storage migration. If you operate a long-running V1 node, you are on a path the README has already marked for removal. That is a maintenance obligation with an unspecified deadline, and it is the single strongest reason to hesitate before adopting Reth for a node you plan to leave untouched for years.

The second is the consensus layer dependency. Reth is an execution client. If you want one binary that handles both execution and consensus, this is not it. The Engine API compatibility statement is a feature, not a gap, but it does mean your operational surface is at least two processes plus whatever validator client sits on top.

The third is the Rust toolchain requirement. MSRV 1.95 is recent, and the workspace uses edition 2024. Teams on older or pinned toolchains will need to move before they can build, and CI images that lag behind will need updating. That cost is real and it recurs, since MSRV moves with the project.

The fourth is the contributor-friendly framing itself. The repository includes AGENTS.md and CLAUDE.md alongside CONTRIBUTING.md, which suggests the project is experimenting with AI-assisted contribution workflows. Whether that helps or hurts review quality is not something the README addresses, and a prospective contributor should look at the contributor docs rather than assume the label. Finally, the README's claim that Reth is production ready and suitable for mission-critical environments is the project's own assessment. The Sigma Prime audit in the audit directory is the independent artifact; read it rather than the sentence.

## Reth Against Geth and Erigon

Geth is the comparison that matters for most operators, and the difference is not just language. Geth is the reference implementation and the default choice: it is written in Go, it is what most tooling assumes, and the README itself notes that Reth's test suite needs Geth installed to run in full. If your team already knows Go and your priority is the widest possible ecosystem compatibility, Geth remains the safe pick and Reth is a deliberate migration, not a drop-in.

Erigon takes a different route to the same problem. Where Reth's pitch is modularity through crates, Erigon's is a reworked database and sync architecture aimed at reducing disk usage and sync time. The practical question for an operator is which resource you are short on. If you want to embed execution into another Rust program, or fork the EVM, Reth's crate layout is the differentiator and neither Geth nor Erigon offers an equivalent. If you want a node binary with the smallest possible operational footprint, that is a different evaluation.

The README also points to the ethPandaOps Lab Dashboard for a third-party comparison of execution timings across clients. That is the right place to look for performance numbers. The assets directory contains a performance chart, but a chart in a project's own README is not an independent measurement, and the README's own framing of Reth as blazing-fast should be treated as a claim to verify rather than a finding.

## Maintenance Cost, Licensing, and Upgrade Path

The last push to the repository was on 2026-09-22, and the most recent release listed is v2.6.0 on 2026-09-17, preceded by v2.5.2 on 2026-09-02 and v2.5.1 on 2026-08-20. Releases arrive on a short cadence, and the jump from 1.0 in June 2024 to 2.0 in April 2026 to 2.6 in September 2026 shows the major version is not a stability promise. Plan for upgrades as routine work, and budget for the storage migration described earlier as the one upgrade you cannot defer indefinitely.

Licensing is unusually permissive. The README says Reth is licensed under the Apache and MIT licenses, and the repository carries LICENSE-APACHE and LICENSE-MIT. Cargo.toml declares MIT OR Apache-2.0. The README's goal list states the project is free for anyone to use any way they want, with no business license restrictions. For a company embedding Reth crates in a product, that is a materially simpler position than a copyleft client. This is a description of the licence files, not legal advice; have counsel review the notices your product ships.

The modularity goal cuts both ways on maintenance. If you import a handful of crates rather than running the node, you inherit the project's release cadence for those crates without inheriting the operational tooling. There is no documented long-term support branch in the documentation available here, so pinning a version and tracking upstream changes is on you. The repository's deny.toml and the Cargo.lock file are the artifacts to watch when you pin.

## Conclusion

Adopt Reth if you run Ethereum infrastructure where performance and cost per node matter, or if you are building an EVM chain and want to reuse the crates instead of writing an execution layer. Do not adopt it if you need a client whose storage format is frozen: V1 databases still work but the README states V1 support will be removed in a future release. Before committing, check whether your node is on V1 or V2 storage and whether you need to migrate, confirm your Rust toolchain is at least 1.95, and read the Sigma Prime audit in the repository's audit directory rather than relying on the production-ready claim in the README.

## FAQ

### What is Reth used for?

Reth is an Ethereum execution layer client: it executes transactions and maintains state, and connects to a consensus layer client over the Engine API. The README also presents it as a set of Rust crates you can import individually to build your own EVM chain or execution-related service.

### Which Rust version does Reth require to build?

The README states the Minimum Supported Rust Version is 1.95, and Cargo.toml declares edition 2024 alongside rust-version 1.95. An older toolchain will fail before it compiles any project code.

### Does Reth need a separate consensus client?

Yes. The README describes Reth as an Ethereum execution layer client that is compatible with all consensus layer implementations supporting the Engine API, so a beacon node or equivalent runs alongside it.

### What changed with Storage V2 in Reth 2.0?

Storage V2 is the default for new nodes in Reth 2.0. Existing V1 nodes continue to work, but the README says V1 support will be removed in a future release and encourages all users to migrate, with V2 snapshots published at snapshots.reth.rs.

### What licence is Reth released under?

The README says Reth is licensed under the Apache and MIT licenses, and the repository contains LICENSE-APACHE and LICENSE-MIT. Cargo.toml declares the workspace licence as MIT OR Apache-2.0.

## Sources

- [License: Apache-2.0](https://github.com/paradigmxyz/reth/blob/main/LICENSE)
- [paradigmxyz/reth on GitHub](https://github.com/paradigmxyz/reth)
- [Project website](https://reth.rs/)
- [README](https://github.com/paradigmxyz/reth/blob/main/README.md)
- [Releases](https://github.com/paradigmxyz/reth/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/paradigmxyz-reth