Rust EVM, an Ethereum Virtual Machine written to be modified rather than used as is

A library with a long history of rewrites

Rust EVM, also known as SputnikVM, is described as a flexible Ethereum Virtual Machine interpreter that can be easily customized. The status section gives the history, and it is unusually candid: the project has a long history dating back to the initial implementation in 2017, when it was called SputnikVM, and it has gone through multiple rewrites over the years to accommodate for different requirements, when the team successfully tested it by integrating Geth to sync the mainnet. The current rewrite is used in production for the Frontier project, which is the Ethereum-compatibility layer for Polkadot, and the project passes the Ethereum test suite. That combination is the strongest evidence in the project documentation: an implementation that syncs a real chain and passes the official test suite is a different category of thing from a toy VM, and the Frontier deployment is a production use rather than a benchmark. Pull requests for fixes are welcomed.

The five properties, and what each one buys you

The feature list is five bullets, each doing a job. Standalone means it can be launched as an independent process or integrated into other apps, so you can run it as a service or link it into a program. Flexible is the important one: it can be customized and extended to support additional opcodes, additional precompiles, different gasometers or other more exotic use cases, and a different gasometer is the detail that matters, because gas is where chains diverge from each other. Portable means it supports no_std and can be used in different environments like in WebAssembly, which is what lets the same execution engine run in a browser, in a proof system or on a microcontroller. Fast is stated with a characteristic shrug, we of course try to be fast. And the last point is the packaging: written in Rust, it can be used as a binary, a cargo crate or a shared library.

The workspace, and the crate split

The Cargo manifest shows a workspace with a deliberate separation. The members are fuzz, interpreter, jsontests with a proc-macro subdirectory, precompile, future, compat and mainnet, plus features/evm64, with the resolver set to 2 and the workspace edition at 2024. The core package is the evm crate itself, which depends on sha3 for the hashing and on the interpreter, and it pulls in the others by path with default features off. The crate names make the roles readable: evm-interpreter is the execution engine, evm-precompile is the precompile set, evm-mainnet is the production configuration, evm-compat is a compatibility layer, and evm-future is where new opcodes are developed before they are production. The features directory with an evm64 entry suggests work on 64-bit word support, which is one of the long-running items in the Ethereum roadmap. The workspace keywords are no_std, ethereum and evm, which is the same summary in three words.

Feature flags, and what they turn on

The feature list on the main package is small and each flag corresponds to a real portability decision. The default is std, which enables the standard library for both sha3 and the interpreter, so the default build assumes a normal hosted environment. The scale feature turns on the interpreter's scale support, and the serde feature turns on its serde support, which is what you need if you want to serialise execution results or configuration across a process boundary. The ruint feature is the interesting one: it switches the interpreter to a different integer representation, and having it as an optional dependency rather than the only option is a performance decision, since the choice of big integer library is one of the hot paths in an EVM implementation. The root crate also lists hex as a dev dependency with the serde feature, which is a test convenience for writing fixtures.

What lives in the directories

The tree shows the testing strategy as much as the code. There is a fuzz/ directory, which is the crate for fuzzing targets, and that is a strong signal for a bytecode interpreter, because an EVM's job is to run arbitrary bytes supplied by anyone. There is a jsontests/ directory with a proc-macro subdirectory, which is the Ethereum state test format: JSON test vectors that the project uses to check conformance. There is a mainnet/ directory holding the production configuration, so the opcode set and gas costs for the live chain are separated from the engine that executes them. The compat/ directory is the compatibility layer, and future/ is where opcodes that do not exist on mainnet yet are developed. The interpreter/ and precompile/ directories are the engine and the precompiled contracts, and there is an examples area implied by the tools/ directory. A rust-toolchain.toml pins the toolchain and a rustfmt.toml pins the formatting.

The version numbers, and the Rust floor

Two version stories meet in this repository, and a reader should notice the gap. The workspace package version is 1.1.1, and the release tags are evm-v1.1.0 from 2025-12-14 and evm-v1.0.0 from 2025-08-18, so the crates have been versioned properly since a 1.0 release in mid-2025. The Rust requirement is where the documentation and the manifest disagree. The README says the project requires at least rustc 1.75, while the workspace manifest sets rust-version to 1.89.0, and the workspace edition is 2024. The manifest is what cargo enforces, so 1.89 is the number to plan around, and the README sentence is simply out of date. The last push to the repository was on 2026-08-06 and it is not archived, so the code is being worked on, with the licence being Apache 2.0.

Where it fits, and what to check before you build

The boundary of this project is clear from the project documentation. It is an execution layer, not a node, not a client and not a wallet, and the people who need it are people building other things: a chain emulator, a proof system, a static analyser, a test harness, or a custom execution environment for a chain that wants Ethereum semantics without inheriting the whole client. The Frontier deployment is the proof that this is a real use and not a research project. The three things to check are therefore concrete. First, whether the opcodes you need are in the mainnet crate or only in the future crate, because a fork that has not activated its new opcodes is a different execution environment and a different gas schedule. Second, that the configuration matches the chain you are emulating, since the gasometer is configurable and the defaults will be mainnet's. Third, the toolchain, where the manifest's 1.89 requirement applies even though the README says 1.75. The fuzzing directory is also worth a look before you trust it with untrusted bytecode, because an interpreter without fuzzing is an interpreter with a bug waiting for an attacker.

Editorial conclusion

Adopt Rust EVM if you are building something that has to execute Ethereum bytecode, such as a chain emulator, a proof system, a static analysis tool or a custom execution environment, and skip it if you want a node, because this is the execution layer, not a client. Verify three things before you build on it: that the opcode set you need is present in the mainnet configuration rather than only in the future crate, since new opcodes live apart from the production one; that the fork configuration matches the chain you are targeting; and the Rust version, because the workspace requires 1.89 while the README still says at least rustc 1.75.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. rust-ethereum/evm on GitHub