RSP proves EVM blocks with Reth inside SP1, and says so plainly: work in progress

A host CLI outside the zkVM drives a client program that runs inside it

The split is the first thing to understand about RSP. Execution happens in Reth, but the proof has to be produced inside a zero-knowledge virtual machine, so the work is divided in two. A host CLI prepares execution data and orchestrates the process. A separate client program runs inside the SP1 zkVM and does the proving. Reth and SP1 are the two upstream projects the code is assembled from: Reth is credited as a highly modular Ethereum execution layer implementation, SP1 as the zkVM that hosts the client. The two halves communicate through storage crates rather than a shared runtime, which is why the workspace has separate host and client executors instead of one program. Nothing in the top-level tree wraps both halves into a single entry point, so a reader looking for one command that does everything will not find it. The documentation lives in its own directory, `book`, separate from the code, and the root page links to a hosted copy at succinctlabs.github.io/rsp.

The workspace lists ten members, and the directory the docs point at is not one of them

The Cargo workspace declares ten members: `bin/host`, `bin/continuous`, `bin/ethproofs`, `crates/executor/client`, `crates/executor/host`, `crates/mpt`, `crates/primitives`, `crates/provider`, `crates/storage/rpc-db` and `crates/storage/witness-db`. That list is the reliable way to see what actually compiles. The directory guide in the root page is looser than the manifest, and it names `bin/client` as the place holding the programs that run inside the zkVM, which the workspace does not list. The same guide repeats `bin/client` twice in one bullet where the first entry was meant to name a different path. Treat the workspace member list as authoritative and the directory guide as approximate. Inside `crates`, the storage layer is split by role rather than by function: `rsp-rpc-db` and `rsp-witness-db` are separate crates, the Merkle Patricia trie gets its own `rsp-mpt` crate built on an arena allocator, `rsp-primitives` holds shared types and `rsp-provider` holds node access.

SP1 is pinned to one exact version in the manifest and again in the image

Two SP1 crates carry a strict pin rather than a range: `sp1-build` and `sp1-core-executor` are both set to `=6.8.1`, and the `=` leaves no room for a patch bump. A manifest comment explains why `sp1-core-executor` is declared at all. It is needed by the host binary for the per-syscall CSV columns keyed on `SyscallCode`, a type the SDK does not re-export, while the GMP backed `bigint-rug` acceleration is taken from `sp1-sdk` so that every binary picks it up. The same version appears in the container build, where the toolchain is fetched, pinned and immediately interrogated:

RUN curl -L https://sp1.succinct.xyz | bash && \
    ~/.sp1/bin/sp1up -v v6.8.1 && \
    ~/.sp1/bin/cargo-prove prove --version

The trailing `prove --version` is the detail worth copying into your own build scripts. It turns a mismatched or missing zkVM into a build failure instead of a failure discovered halfway through proving.

A Dockerfile with three stages that ends in a version check

The image is built on a cargo-chef base, which gives the build a dependency-caching layer. The first stage installs the system packages the Rust build needs, `libclang-dev` and `pkg-config`. A planner stage then copies the tree and runs `cargo chef prepare` to produce a recipe, and a builder stage cooks that recipe with `--profile release` before any project code is copied in. A third stage forks off the builder for the continuous binary and carries a comment admitting that `ARG` is not resolved inside `COPY`, so the source has to be copied in to work around it:

RUN cargo build --profile release --locked --bin continuous

`--locked` is the flag that matters. It refuses to proceed if the lock file does not already satisfy the manifest, which for a workspace holding an exact SP1 pin is the difference between a reproducible image and one that quietly resolves a different prover version. The builder stage also installs `jq` and a stable Rust toolchain, so the compiler used in the image is not tied to whatever toolchain the cargo-chef base happened to ship.

Release tags pair a reth version with an sp1 version

The three most recent tags follow a naming pattern rather than a version series: `reth-2.2.0-sp1-6.8.1`, `reth-2.2.0-sp1-6.8.0` and `reth-2.2.0-sp1-6.5.0`. The reth half has not moved across all three, while the SP1 half has climbed from 6.5.0 to 6.8.1. Read as a pair, each tag tells you which combination of execution client and zkVM a release was cut against, which matters because RSP bridges the two and a mismatch is exactly what a single flat version number would hide. The newest tag, `reth-2.2.0-sp1-6.8.1`, is dated 2026-09-26, and the same date is the most recent commit to the repository. The manifest pin, the version installed in the image and the newest tag therefore all agree on SP1 6.8.1 today, and the two earlier tags, from 2026-09-11 and 2026-08-27, show how short the intervals between such pairings are.

The example environment file has four empty RPC slots and one prover key

The checked-in template carries no secrets and no working endpoints, so nothing runs until you fill it in. Four RPC variables are named by chain ID rather than by network nickname, and all four are blank in the template:

RPC_1=
RPC_10=
RPC_59144=
RPC_11155111=
# environment variables for prover network
SP1_PROVER=network
SP1_PRIVATE_KEY=

Two of the chain IDs are low numbers and two are much larger, so the set spans more than one kind of network, but the file never says which chain is which and the hosted documentation would have to. Below them, a comment labels the last two as environment variables for the prover network, and `SP1_PROVER` is the only line with a value: `network`. `SP1_PRIVATE_KEY` is left empty. That pairing is the operational decision in this file. With the prover set to `network`, the host CLI hands proving work to a remote prover service rather than proving locally, and the key is what authenticates it.

Cargo.toml still points at a different repository than the one you cloned

The shared workspace metadata sets `repository` and `homepage` to `https://github.com/moongate-forks/minimal-reth`. Neither field names the repository that actually holds this code, and the name itself hints at where the code started, as a minimal reth fork. Anyone who follows that metadata from a package page, a crate listing or a generated file header lands on a different project. The version field has the opposite problem: it is a flat `0.1.0` for the entire workspace, so it carries no information about which reth or SP1 a given build expects, which is the very thing the release tags do encode. The edition is set to 2021 with resolver version 2, and `exclude` is set to `**/target` so packaging skips build output. Nothing there breaks a build, but those two URL fields are the kind of detail to distrust until you have confirmed them against the repository you are actually reading.

An audits directory sits next to a banner saying nothing here is audited

The top-level tree lists `audits/`, and also `Justfile`, `rust-toolchain.toml` and `rustfmt.toml`, none of which the root page explains. The tension is worth naming plainly. The tree contains a directory reserved for audits, and the project describes itself as an active work-in-progress that is not audited and not meant for production usage. A directory existing says nothing about the state of the code; the banner is the statement to plan around. A `Justfile` means there are task shortcuts defined somewhere, and a `rust-toolchain.toml` means the toolchain is pinned rather than whatever happens to be installed locally, which matters for a workspace this size. If either matters to you, read those two files first. The honest summary of RSP today is a small, cleanly partitioned Rust workspace that shows the host and zkVM halves of Reth based proving, still short of a release anyone should point real traffic at.

Editorial conclusion

Use RSP if you want a small, readable Rust example of how Reth execution code gets driven inside an SP1 zkVM, and you are prepared to read the source rather than a finished tool. Skip it for anything production facing, since the repository carries an explicit not audited, not for production banner. Before you build, check that the SP1 pin still matches the zkVM you install, that the reth and sp1 pair in the newest release tag is the one you want, and that the repository and homepage fields in Cargo.toml, which still point at a different repository, have been corrected.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes