reth

Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol

Install | User Docs | Developer Docs | Crate Docs

What is Reth?

Reth (short for Rust Ethereum, pronunciation) is a production-ready Ethereum execution layer client focused on modularity, performance, and user-friendliness. Reth is compatible with all Ethereum Consensus Layer (CL) implementations that support the Engine API. It is built and driven forward by Paradigm, and is licensed under the Apache and MIT licenses.

Note: OP-Reth has moved to ethereum-optimism/optimism. Git history has been preserved.

Goals

1. Modularity: Every component is built to be used as a library: well-tested, documented and benchmarked. Import crates, mix and match, and innovate on top of them. Learn more about the project's components here.
2. Performance: Built with Rust, Alloy, revm, and Foundry — battle-tested and optimized for speed. Check the ethPandaOps Lab Dashboard for a third-party comparison against other Ethereum clients. Here's what that looks like in practice, measured with reth-bench on Ethereum Mainnet:

3. Free for anyone to use any way they want: Apache/MIT licensed, no business license restrictions.
4. Client Diversity: More client implementations make Ethereum more antifragile.
5. Support as many EVM chains as possible: Reth can sync Ethereum and other EVM chains. If you're building one, reach out.
6. Configurability: Profiles for different use cases — from high-performance RPC operators to hobbyists on consumer hardware.

Status

Reth is production ready, and suitable for usage in mission-critical environments such as staking or high-uptime services. We also actively recommend professional node operators to switch to Reth in production for performance and cost reasons in use cases where high performance with great margins is required such as RPC, MEV, Indexing, Simulations, and P2P activities.

• We released Reth 2.0 in April 2026. See the release notes and blog post.
• We released 1.0 "production-ready" stable Reth in June 2024.
  • Reth completed an audit with Sigma Prime, the developers of Lighthouse, the Rust Consensus Layer implementation. Find it here.
  • Revm (the EVM used in Reth) underwent an audit with Guido Vranken (#1 Ethereum Bug Bounty).
• We released multiple iterative beta versions, up to beta.9 on Monday June 3, 2024, the last beta release.
• We released beta on Monday March 4, 2024, our first breaking change to the database model, providing faster query speed, smaller database footprint, and allowing "history" to be mounted on separate drives.
• We shipped iterative improvements until the last alpha release on February 28, 2024, 0.1.0-alpha.21.
• We initially announced 0.1.0-alpha.1 on June 20, 2023.

Storage compatibility

Storage V2 is the default for new nodes in Reth 2.0. Existing V1 nodes continue to work, but V1 support will be removed in a future release — all users are encouraged to migrate. V2 snapshots are available at snapshots.reth.rs.

For Users

See the Reth documentation for instructions on how to install and run Reth.

For Developers

Using reth as a library

You can use individual crates of reth in your project.

The crate docs can be found here.

For a general overview of the crates, see Project Layout.

Contributing

If you want to contribute, or follow along with contributor discussion, you can use our main telegram to chat with us about the development of Reth!

• Our contributor guidelines can be found in CONTRIBUTING.md.
• See our contributor docs for more information on the project. A good starting point is Project Layout.

Building and testing

The Minimum Supported Rust Version (MSRV) of this project is 1.93.0.

See the docs for detailed instructions on how to build from source.

To fully test Reth, you will need to have Geth installed, but it is possible to run a subset of tests without Geth.

First, clone the repository:

git clone https://github.com/paradigmxyz/reth
cd reth

Next, run the tests:

cargo nextest run --workspace

# Run the Ethereum Foundation tests
make ef-tests

We highly recommend using cargo nextest to speed up testing. Using cargo test to run tests may work fine, but this is not tested and does not support more advanced features like retries for spurious failures.

Note

Some tests use random number generators to generate test data. If you want to use a deterministic seed, you can set the SEED environment variable.

Getting Help

If you have any questions, first see if the answer to your question can be found in the docs.

If the answer is not there:

• Join the Telegram to get help, or
• Open a discussion with your question, or
• Open an issue with the bug

Security

See SECURITY.md.

Acknowledgements

Reth is a new implementation of the Ethereum protocol. In the process of developing the node we investigated the design decisions other nodes have made to understand what is done well, what is not, and where we can improve the status quo.

None of this would have been possible without them, so big shoutout to the teams below:

• Geth: We would like to express our heartfelt gratitude to the go-ethereum team for their outstanding contributions to Ethereum over the years. Their tireless efforts and dedication have helped to shape the Ethereum ecosystem and make it the vibrant and innovative community it is today. Thank you for your hard work and commitment to the project.
• Erigon (fka Turbo-Geth): Erigon pioneered the "Staged Sync" architecture that Reth is using, as well as introduced MDBX as the database of choice. We thank Erigon for pushing the state of the art research on the performance limits of Ethereum nodes.
• Akula: Reth uses forks of the Apache versions of Akula's MDBX Bindings, FastRLP and ECIES. Given that these packages were already released under the Apache License, and they implement standardized solutions, we decided not to reimplement them to iterate faster. We thank the Akula team for their contributions to the Rust Ethereum ecosystem and for publishing these packages.

Warning

The NippyJar and Compact encoding formats and their implementations are designed for storing and retrieving data internally. They are not hardened to safely read potentially malicious data.