Summary: OpenVM is a modular zkVM framework, not a category anchor. The useful mechanism is the no-CPU architecture: keep the system chips thin, then add functionality through VM extensions that bundle guest instructions, transpiler logic, and circuit chips together. That makes OpenVM a good lower-layer comparison point for proving stacks because the control surface sits in ISA design, extension authorship, transpilation, continuation policy, and the proving pipeline — not just headline proof speed.
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.