ethrex completes its first external security audit

ethrex, our Ethereum execution client, has completed its first external security audit. Least Authority reviewed the client between January and May 2026 and identified 20 issues and 8 suggestions. The final report, delivered on May 4, verified that every issue was addressed. Both reports are published in the repository.

What ethrex is

ethrex is a minimalist implementation of the Ethereum protocol, written in Rust. It runs in two modes: as an execution client on Ethereum mainnet, and as a ZK-rollup stack in which the same client sequences an L2 and proves block execution on the zkVM of your choice (SP1, RISC Zero, ZisK, OpenVM) or on TEEs. From the start, we built the execution core to run in two places: natively when following the chain, and inside a zkVM when proving blocks.

We built ethrex around one idea: simplicity. The client weighs roughly 100,000 lines of Rust, while mature clients exceed 500,000. We keep dependencies to a minimum, avoid abstractions until they earn their place, and skip speculative features. Our engineering philosophy covers the reasoning.

Size also determines what an audit can cover. External reviewers can read this client end-to-end, and they did. On a codebase five times larger, the same review covers a fraction.

The audit

Least Authority is a security consultancy known for reviews of cryptographic protocols and distributed systems. A team of five security and cryptography researchers spent three weeks on ethrex v9.0.0, covering LEVM (our EVM implementation), the smart contracts, the sequencer, the prover and its zkVM backends, the networking and RPC layers, and the hand-written Keccak and Blake2 assembly in our crypto crate.

The initial report listed 20 issues and 8 suggestions. We fixed the findings, and Least Authority verified each fix before delivering the final report. Verification ran against v11.0.0, two major releases past the audited revision: the client kept shipping while the audit ran, and the auditors checked the fixes against the current code.

The final report's tally:

Of the 8 suggestions, 5 are resolved, and 3 remain open as ongoing work on test coverage, code comments, and prover code quality.

The issues clustered around block validation edge cases, atomicity of transaction finalization, liveness of the proving pipeline, and input handling in the assembly code.

The report describes the code as "well organized and straightforward to navigate," the VM as "well written and clear to reason about," and the scope as having "included all security-critical components." It also calls our test coverage insufficient. That criticism was fair, and it shaped the remediation: every fix landed with regression tests, and coverage of VM edge cases and contract invariants keeps growing.

How we handled the findings

Every finding has a public answer. The verification response maps each issue to the pull request that fixes it, so you can read the diff behind every "resolved" in the table above.

Some fixes went further than the report required. Two findings in the Blake2 and Keccak assembly were unreachable in practice, because the Rust callers validate inputs before the assembly runs. We hardened the assembly anyway; it now stays safe even if a future caller skips validation.

For three findings, we pushed back. We argued the design was sound, citing the Ethereum execution specs and the behavior of other clients, and the auditors agreed: the final report marks them as non-issues. We fixed every confirmed bug and provided evidence where we disagreed.

We also updated the dependencies flagged by cargo audit. One transitive dependency remains on an advisory list: the vulnerable code path only ever receives compile-time constants, and the response page documents why its impact is zero.

Security work continues past the final report. The client runs the Ethereum Foundation's execution spec tests in CI, and the regression suites started during remediation keep growing.

Where ethrex stands

ethrex is ready for production use:

• On mainnet. It runs as an execution client on Ethereum mainnet today, syncing on modest hardware: 4–8 cores, 32 GB of RAM, and a 1 TB NVMe disk.
• Run by operators. Staking operators run ethrex in production, among them Serenita, Stakely, and RockLogic, plus distributed validator clusters in the Obol Collective.
• Run by home stakers. eth-docker, the EthStaker community's node stack, ships built-in ethrex support.
• Tested like the rest of the network. It runs the Ethereum Foundation's execution spec tests and the cross-client hive suites in CI, with daily reports.
• Proving Ethereum. It proves mainnet blocks with several zkVM backends on Ethproofs.
• Running as a ZK L2 stack. It includes a sequencer, prover, and bridge contracts.
• Moving with the protocol. It already runs on the devnets for Glamsterdam, the next network upgrade, where we implement and test the upcoming EIPs alongside the other client teams.

Most of that list is out of our hands: other teams' stake runs on ethrex, the community's tooling ships it, and the same test suites and devnets that gate every client gate this one. Ethereum's resilience depends on independent implementations, and clientdiversity.org already lists ethrex among the stable choices.

Ethereum on ARM, the project that turns ARM boards into full Ethereum nodes, ran ethrex for a month inside an Obol Collective distributed validator cluster and wrote on X:

Totally impressed with the ethrex Execution Layer client: 500 GB database, minimal CPU load, rock solid stability. [...] It is a synced Full Node. We use it for staking so it is fully functional.

Read the reports

You can find the official reports and the response in the ethrex GitHub repository:

• Initial audit report (v9.0.0, PDF)
• Final audit report (v11.0.0, PDF)
• Verification response, finding by finding

It can be found in Least Authority website too.

To run a node, start with the getting started guide. Questions and feedback are welcome on GitHub, Telegram, or X.