Summary: OpenVM is worth cataloging not as just another zkVM brand, but as a framework that tries to make the virtual-machine boundary itself modular. Its core move is to remove the idea of a monolithic CPU-centric zkVM and replace it with a no-CPU architecture where required system chips stay minimal and new functionality is added through VM extensions that simultaneously introduce guest-side instructions, transpiler logic, and circuit chips. That makes OpenVM analytically useful as a lower-layer comparison point beneath prover networks and application-facing zk products: the main control surface is not just proof speed, but who controls the ISA, extension crates, transpilation path from RISC-V into OpenVM assembly, continuation/segmentation rules, and the hardware-accelerated proving path.
What it does:
Provides an open-source zkVM framework designed for custom VM construction rather than one fixed machine design
Uses a no-CPU architecture where core system chips stay fixed and extension-specific chips implement most higher-level functionality
Supports a default extension set including RV32IM, native field arithmetic, Keccak-256, SHA2-256, BigInt, modular algebra, elliptic-curve operations, and pairings
Lets developers extend the machine through a three-part VM extension flow: guest library, transpiler extension, and circuit extension
Uses Rust as the main frontend, compiling programs to a 32-bit RISC-V ELF and then transpiling that into OpenVM assembly with extension-aware custom instructions
Supports continuations and proof aggregation so unbounded programs can be segmented and proven in parallel
Describes a distributed proving architecture where metered execution segments programs on CPU machines, trace generation happens on accelerator devices, and segment proofs are aggregated through a continuation tree
Key claims:
The README’s most important signal is the “modular no-CPU architecture” claim. That is stronger than generic modularity rhetoric because it means OpenVM is explicitly trying to make custom chips first-class without requiring a fork of the core VM architecture.
The design/specs docs make the next control surface explicit: OpenVM is a framework to co-design a custom zkVM, ISA, and language frontend simultaneously. That matters because the project is packaging runtime design, instruction design, and compiler/toolchain design as one extensible stack rather than treating them as separate downstream choices.
The extension model is the main reusable mechanism. The docs say every new VM extension should split into a guest library, transpiler extension, and circuit extension. That decomposition is exactly why OpenVM belongs in the active corpus: it makes opcode authorship, language integration, and proof-circuit implementation legible as separate layers.
The ISA docs are also useful because OpenVM does not simply emulate one conventional machine. It explicitly supports multiple machine architectures and multiple address spaces, variable word size, and extension-specific instructions that can appear either as Rust intrinsics or kernels. This makes it a strong comparison point for other zkVMs that hide major control surfaces inside compiler patches or precompile catalogs.
The distributed proving docs show that OpenVM is not only a VM design but also a proving pipeline design: metered execution chooses segments, preflight execution records trace-relevant state, trace generation is hardware-parallelized on device, and proof aggregation proceeds through a continuation tree. That makes continuation policy and host/device boundaries part of the actual product surface.
OpenVM clears the corpus bar because it makes zkVM modularity unusually explicit at the ISA, chip, compiler, continuation, and proving-architecture levels. If it stayed folded into a generic zkVM bucket, the extension control plane would be easy to miss.
Whitepaper: OpenVM has an official whitepaper at https://openvm.dev/whitepaper.pdf, downloaded in this pass to ../whitepapers/openvm-whitepaper.pdf. The most accessible primary-source text used here was still the README plus the design/specs and distributed-proving docs; see ../whitepapers/openvm-primary-sources-2026-05-13.md.