OpenVM

Announcing Formal Verification of OpenVM RV32IM Constraints in Lean

2026-02-10T16:41:05+00:00

Today we are announcing that the functional correctness of the OpenVM RV32IM extension has been formally verified in Lean by Nethermind Research with support from an Ethereum Foundation grant. This marks the first step in incorporating formal methods into the OpenVM development process, which we intend to maintain as a standard component of our ongoing security strategy.

This verification ensures that the statements proven in ZK by OpenVM match the official SAIL specification for RISC-V by proving that OpenVM polynomial constraints exactly codify RV32IM opcode functionality. No ZK circuit bugs were found in OpenVM’s implementation of RISC-V opcodes in the course of verification, giving users a formal assurance that there are no missing constraints that could lead to critical soundness vulnerabilities.

In addition to covering all 45 RV32IM opcodes, this work also verified correctness of execution and memory consistency, going beyond previous formal verification efforts for zkVMs. We assumed the correctness of the LogUp multiset consistency arguments in OpenVM, which will be the subject of future formal verification work.

What was verified

To formally verify the OpenVM RV32IM extension, Nethermind first built tooling to extract the underlying polynomial constraints from each OpenVM AIR written in the Plonky3 ZK frontend. This resulted in a representation of the constraints as polynomial equations in Lean. Nethermind then proved that these polynomials imply the functional relation between opcode inputs and outputs as codified in the standard SAIL specification for RISC-V.

The result of the process was Lean proofs covering all 45 RV32IM opcodes, spanning:

ALU opcodes (27): ADD, ADDI, SUB, XOR, XORI, OR, ORI, AND, ANDI, SLT, SLTI, SLTU, SLTUI, SLL, SLLI, SRL, SRLI, SRA, SRAI, MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU
Control-flow opcodes (10): AUIPC, BEQ, BNE, BLT, BGE, BLTU, BGEU, LUI, JAL, JALR
Memory manipulation opcodes (8): LW, LH, LHU, LB, LBU, SW, SH, SB

These proofs ensure that there are no missing or conflicting constraints in the opcode circuits, which implies functional correctness of OpenVM’s handling of RISC-V, including memory and execution consistency. This verification focused on the OpenVM frontend and assumed the correctness of the LogUp multiset equality argument and underlying proof system comprising the OpenVM backend. These will be the focus of future verification efforts as we expand the scope of formal methods in OpenVM.

We are open-sourcing the verification infrastructure and artifacts:

The verification tooling to extract Plonky3 constraints from OpenVM chips is available at Nethermind’s forks of OpenVM and STARK-backend. In future work, these will be merged into the main OpenVM repos
The Lean proofs for each RV32IM opcode are available open-sourced here
The full verification report can be found here

We plan to accompany future releases with updates to this verification infrastructure to ensure OpenVM remains continuously formally verified.

OpenVM is moving to provable security

In tandem with this milestone, OpenVM is making a broader move toward provable security. Today we are announcing a new OpenVM 1.5.0 release with 100 bits of provable security, available on GitHub under MIT and Apache 2.0 dual-license. The upcoming OpenVM 2.0 release will also feature 100 provable bits of security, and we are actively working towards 128 bits of provable security. Together, these efforts push OpenVM toward a future where the strength and correctness of its security are backed by rigorous formal methods without reliance on conjectures.

To stay up to date with new OpenVM developments, join our developer Telegram and follow us on X. Until then, you can find our open-source code on GitHub – see you there!

Announcing OpenVM 2.0, Powered by SWIRL

2026-02-10T00:04:47+00:00

We are excited to announce OpenVM 2.0 and the SWIRL proof system. OpenVM 2.0 proves mainnet Ethereum blocks in real time at a p99 level and proves RISC-V programs at 139 MHz on a cluster of 16 5090 GPUs with 100 bits of provable security. This represents a 3x+ improvement over the initial OpenVM GPU release in September 2025. It is powered by SWIRL, a new multilinear proof system featuring blazing-fast recursion, post-quantum security, proof sizes under 300 kB, and a new ahead of time (AOT) single-pass compiler for execution at 3.8 GHz.

With this release, OpenVM 2.0 meets the performance targets defined by the Ethereum Foundation for L1 zkEVMs and proves at speeds similar to the clock speed of some embedded processors. These advances allow us to continue enabling developers to tailor ZK for their needs, now with greatly improved proving efficiency and latency.

OpenVM 2.0 will be open-sourced shortly under MIT and Apache 2.0 dual license on GitHub. We are also releasing a SWIRL whitepaper with a formal specification and security proofs. If you’d like to chat about using or customizing OpenVM 2.0 for your needs, join our developer Telegram.

Performance Benchmarks

OpenVM 2.0 brings 3x+ performance improvements over previous GPU releases and is now approaching non-trivial processor clock speeds. To evaluate performance for blockchain workloads, we generated STARK proofs for Ethereum mainnet blocks and measured end-to-end proving time. All benchmarks were run on a bare metal cluster of 16 5090 GPUs with security parameters ensuring 100 bits of provable security and proof sizes under 300 kB.

On a recent stretch of 1000 mainnet blocks, OpenVM 2.0 achieves real-time proving on 16 GPUs with p99 proving time of 11.8s and average proving time of 6.7s, meeting the performance and security targets for Ethereum L1 set by the Ethereum Foundation.

[email protected]" loading="lazy" srcset="https://blog.openvm.dev/media/[email protected] 1588w, https://blog.openvm.dev/media/[email protected]/500w 500w, https://blog.openvm.dev/media/[email protected]/750w 750w, https://blog.openvm.dev/media/[email protected]/1000w 1000w, https://blog.openvm.dev/media/[email protected]/1500w 1500w">

Benchmarks run on 16 bare-metal 5090 GPUs for blocks 24,000,000 to 24,000,999

On mainnet block 21,000,000, which we’ve evaluated since the initial v0.1 release of OpenVM, OpenVM 2.0 continues the trend of consistent decreases in proving time, representing an over 60x improvement in the last year.

OpenVM 2.0 benchmarks run on 16 bare-metal 5090 GPUs

We also compared against the previous GPU release of OpenVM from October 2025 on mainnet blocks 22,000,000 to 22,000,999. We see substantial cost and latency improvements across a wider range of blocks.

OpenVM 2.0 benchmarks run on 16 bare-metal 5090 GPUs

To evaluate raw throughput on general purpose workloads, we are introducing a new benchmark based on CoreMark, the industry standard for measuring embedded CPU performance. On an adaptation of CoreMark to RV32IM, OpenVM 2.0 sustains proving speeds of 11.4 MHz on a single 5090 GPU and 139 MHz on a cluster of 16 5090 GPUs.

Benchmarks run on bare metal 5090 GPUs

The SWIRL Proof System

OpenVM 2.0 is built on SWIRL, a new multilinear proof system designed from the ground up to handle the complex, heterogeneous architecture of modern zkVMs. It features 100 bits of provable security, is post-quantum, and does not rely on a trusted setup.

The system’s backbone is WHIR, a multilinear polynomial commitment scheme we selected for its highly efficient Reed-Solomon proximity testing. SWIRL does not incur performance penalties in the prover or verifier when handling complex circuit designs with diverse sub-components. SWIRL uses modular applications of sumcheck to interoperate between different polynomial domains -- each phase of the protocol uses the domain most suitable for performance. These phases involve customizations of Zerocheck and Logup-GKR, together with a Stacked Reduction to link everything with WHIR. We further optimize the resulting sumchecks for small fields with a reformulated version of the Univariate Skip.

We are also introducing a new blazing fast recursion for SWIRL. By using write-once memory and limited dynamism, we are able to preserve the performance of a fixed recursion circuit while aggregating a dynamic number of proofs. To learn more about the cryptography and security proofs behind SWIRL, check out the new whitepaper.

AOT Execution for OpenVM

With the substantial proof system improvements in OpenVM 2.0, execution was initially a bottleneck in end-to-end proving. To address this, OpenVM 2.0 introduces a new ahead of time (AOT) execution system that executes RISC-V assembly at a near-native 3.8 GHz as well as execution improvements for elliptic curve operations.

Execution benchmarks run on AMD EPYC 9355 CPUs

AOT execution performs a single-pass compilation of OpenVM binaries to x86 assembly, achieving a 7.8x speedup over an optimized interpreter on the CoreMark benchmark and dropping execution time from 1.8s to 0.5s on Ethereum block 24,000,000.

What’s Next

We are actively working to bring OpenVM 2.0 to production. OpenVM 2.0 will be supported shortly in preview mode on the Axiom Proving API, and a production release will follow after a full security process including external security reviews. In conjunction with this, Axiom is actively integrating OpenVM 2.0 into ZK-enabled products across the ecosystem; if you are interested in deeper support to use OpenVM for your product, reach out here.

In the coming months, we are excited to continue pushing the frontiers of ZK by incorporating new techniques across proof systems, ZK frontends, and compilers into OpenVM. We are especially excited about the new design tradeoffs SWIRL enables for different ZK applications. To stay updated or collaborate, reach out on Telegram or X.

In the meantime, you can find us on Github as always!

Releasing OpenVM 1.4.1

2026-02-10T00:04:47+00:00

We are releasing OpenVM v1.4.1 today under MIT and Apache 2.0 dual-license on Github. This release introduces a new Virtual Pool Memory Manager in the GPU prover as well as several memory access optimizations in our Cuda kernels. These provide substantial performance gains, dropping average latency for Ethereum mainnet blocks under 12 seconds and enabling proving cost as low as $0.0001 per transaction.

To evaluate, we generated STARK proofs for Ethereum mainnet blocks using L40S GPUs on 64 g6e.2xlarge instances on AWS. We measured end-to-end proving times as well as proving cost per transaction. On blocks 21,000,000 to 21,000,003, OpenVM v1.4.1 shows marked improvements in latency and cost.

64 g6e.2xlarge instances on AWS, details here

We also generated proofs for the 1000 block range of mainnet blocks between 22,000,000 and 22,000,999 to compare with OpenVM v1.4.0 from September 2025, which show these cost and latency improvements persist across a wider range, achieving average case real-time proving over this range.

64 g6e.2xlarge instances on AWS, details here

OpenVM v1.4.1 has been audited by Cantina and is recommended for production usage. Day 1 hosted proving support is also available through Axiom on the Axiom Proving API. Check out our docs to get started with OpenVM, and stay updated via our developer chat on Telegram and the code on Github.

Announcing GPU Proving for OpenVM

2026-02-10T00:04:47+00:00

We are releasing OpenVM v1.4.0 today under MIT and Apache 2.0 dual-license. This release includes a new GPU prover for OpenVM, new execution system running at 150 MHz, and multi-GPU orchestration for parallel proving on hundreds of GPUs. OpenVM can now verify mainnet Ethereum blocks for under $0.0003 per transaction and in 15s on GPU, an additional 5x+ improvement over the v1.0.0 release in March 2025.

We are excited for developers to continue using OpenVM to tailor ZK for their needs, now with substantial performance improvements across execution and proof generation. By shipping with a fully open-source GPU prover, this release enables developers to run and customize OpenVM however makes the most sense for their use case.

OpenVM v1.4.0 is available under MIT / Apache 2.0 license on Github and is recommended for production usage after an audit by Cantina. This release also comes with a substantial update to the developer docs including specs for our new distributed proving design. If you’d like to chat about using or customizing OpenVM for your needs, join our developer Telegram.

Inside OpenVM v1.4.0: GPU Prover and Distributed Proving

The core feature in this v1.4.0 release is a new GPU prover for OpenVM. Developers can now dramatically speed up proving times with GPU acceleration for both proving and trace generation. The new GPU prover supports all Nvidia GPUs with at least 24GB of VRAM, including the L40, RTX 4090, L40S, and RTX 5090 cards widely available for both self-hosted and cloud support. It supports trace generation and proving fully end-to-end on the GPU, with no intermediate host-device communication to minimize latency.

We are releasing the GPU prover under the same MIT / Apache 2.0 dual license as the rest of OpenVM v1.4.0. This enables developers to use GPU acceleration in the most flexible way possible, particularly in different containerized or on-prem hosting environments. We also look forward to seeing customizations and optimizations from the community for different use cases!

Multi-GPU distributed proving architecture for OpenVM

In conjunction with GPU acceleration, we’ve shipped a redesign of OpenVM execution and trace generation to facilitate multi-GPU distributed proving. As illustrated above, after a preparatory metered execution, OpenVM now generates traces and proofs fully in parallel, with all non-execution work happening purely on the GPU. This distributed proving support scales to clusters with hundreds of GPUs and can accommodate heterogeneous GPU backends.

Finally, to make distributed proving performant, we’ve substantially optimized OpenVM execution via an optimized interpreter now running at 150 MHz. This incorporates direct memory mapping, tail call optimization, and extension- and host-specific acceleration to dramatically improve performance in a way which will generalize across extensions. In the distributed setting, the new execution dramatically reduces proving latency from the serial metered execution.

A guide to using OpenVM on GPU is included in our updated developer book. To learn more about the architecture underlying the multi-GPU distributed proving and execution, check out the new specs.

Performance Updates

OpenVM v1.4.0 can prove Ethereum mainnet blocks for ~$0.0003 per transaction and in 15s on GPU machines. This is another 5x+ improvement over our March 2025 production release and was enabled by the new OpenVM GPU prover and a complete rewrite of execution and trace generation, most notably to move trace generation entirely onto the GPU.

To evaluate performance, we generated STARK proofs for Ethereum mainnet blocks on both a single GPU machine and multiple GPU machines using the new distributed proving architecture. We measured end-to-end proving times as well as proving cost per transaction. All benchmarking was done on L40S GPUs on g6e.2xlarge instances on AWS, and we expect a further 2x performance improvement by switching to 5090 GPUs.

On the mainnet blocks we’ve evaluated since the v0.1 and v1.0.0 releases, OpenVM v1.4.0 achieves substantial decreases in cost and latency driven by the new GPU accelerated backend.

g6e.2xlarge on AWS, details here

We also generated proofs for a 1000 block range of mainnet blocks with numbers between 22,000,000 and 22,000,999 to compare with OpenVM v1.0.0 benchmarks from March 2025. We see similar decreases in proof cost and latency, and also measure the new OpenVM v1.4.0 interpreter running at 155 MHz on this set of blocks.

g6e.2xlarge on AWS, details here

To evaluate OpenVM performance along different functional directions, we benchmarked a range of tasks including ECDSA and BLS signature verification and iterated SHA2-256 hashing.

g6e.2xlarge on AWS, details here

These benchmarks are reproducible via our Reth benchmark repo here. As always, we are excited to continue our work to serve more developer use cases by making ZK cheaper and faster.

What’s Next

We are excited to see developers benefit from the cost and latency improvements packed into this release as they deploy OpenVM in production. As part of the open design philosophy behind OpenVM, we look forward to seeing developers run the open-source GPU prover flexibly across hosting setups and customize for their specific GPU or use case. Day 1 hosted proving support is also available through Axiom on the Axiom Proving API.

Looking forward, we will continue to push the envelope on performance by innovating on proof systems, zkVM design, and hardware acceleration. We’ve also started work on using OpenVM’s modular design to tailor custom zkVMs for specific use cases – we’ll have more to share here in the coming months. To learn more or collaborate, reach out on Telegram or X.

To try out OpenVM today, check out:

OpenVM developer book: A developer guide for using OpenVM to generate ZK proofs for Rust programs and customizing OpenVM for your use case.
OpenVM specifications: Technical specifications for OpenVM, updated with our new distributed proving and refreshed execution framework.

We’re excited to see what you will build with OpenVM – see you on Github!

Releasing OpenVM 1.3.0

2026-02-10T00:04:46+00:00

Today we are releasing OpenVM v1.3.0, available on Github dual-licensed under MIT and Apache 2.0. This release contains several features to improve developer experience, including:

Updated guest libraries: We updated the default OpenVM guest libraries to provide more ergonomic developer interfaces patching popular crates including k256, p256, and ruint. Users of OpenVM can now access all functionality of the default VM extensions through these libraries alone.
Verify STARK library: We’ve added a new openvm-verify-stark library which enables verification of OpenVM STARK proofs from within Rust programs in OpenVM.
OpenVM CLI: We’ve updated the OpenVM CLI to support all common Cargo options, including multiple targets, package selection, and feature selection.

OpenVM v1.3.0 has been audited by Cantina and is recommended for production usage. As always, you can follow continued development of OpenVM in the developer chat on Telegram, and we’ll see you on Github!

Releasing the OpenVM Solidity SDK

2026-02-10T00:04:46+00:00

Today we are releasing the OpenVM Solidity SDK, which makes it easy for developers to verify OpenVM proofs onchain. The Solidity SDK supports any zkVM constructed with the modular OpenVM framework and can be directly imported into your Foundry project for the default OpenVM configuration.

Developers can use the OpenVM Solidity SDK to deploy Solidity verifiers for OpenVM proofs on any EVM chain. It ships as a Foundry library with support for the default OpenVM configuration and also supports generating verifiers for custom OpenVM configurations. In all configurations, developers can verify Halo2 proofs generated by OpenVM onchain for under 330K gas.

The OpenVM Solidity SDK is available today in the v1.1.2 release of OpenVM under MIT license on Github. It was audited by Cantina and is recommended for production usage. To try the OpenVM Solidity SDK today, check out:

Solidity SDK docs: A developer-focused guide to using and deploying onchain verifiers for OpenVM in the OpenVM developer docs.
Foundry library: Directly import the Solidity SDK into your Foundry project using our library on Github.

To stay up to date with our continuing development of OpenVM, join our developer Telegram. Until then, you can find our open-source code on Github – see you there!

Announcing the OpenVM Release

2026-02-10T00:04:46+00:00

After almost one year of development and a competitive audit by Cantina, we are excited to release the first production v1.0.0 version of OpenVM. OpenVM v1.0.0 is the next step in our mission to build a modular zkVM framework that provides developers extensibility without tradeoffs on performance. With this release, OpenVM is recommended for production and can verify Ethereum mainnet blocks for $0.0015 per transaction and under 3 minutes on CPU, a 5x+ improvement from the initial v0.1 release.

Developers can use OpenVM to generate ZK proofs that verify the execution of arbitrary Rust programs, accelerate proving with custom VM extensions, and verify proofs on-chain efficiently. The modular OpenVM zkVM framework enables developers to further tailor the ISA, ZK circuits, and proof system to their use case for the most optimal performance.

The v1.0.0 release of OpenVM is available today under MIT license on Github and is recommended for production usage. We are also releasing an OpenVM whitepaper providing a formal specification of our novel no-CPU zkVM design and audit reports from our Cantina competition and an internal audit by the Axiom team.

To learn more, check out the developer book, whitepaper, and Github. If you’d like to chat about using or contributing to OpenVM, join our developer Telegram.

What’s Supported in OpenVM 1.0.0

OpenVM v1.0.0 is a full-featured and performant zkVM framework which can generate ZK proofs for arbitrary Rust programs. OpenVM can handle programs as diverse and complex as Revm, Reth, or rollup state transition functions (like Scroll), and ships with:

A Rust frontend supporting std and no-std programs via compilation to RISC-V.
Verification of unbounded length programs via continuations and proof aggregation.
A Solidity verifier to efficiently verify OpenVM proofs in EVM.
A robust set of VM extensions allowing developers to efficiently verify operations like the following efficiently from within standard Rust programs:
- SHA2-256 (new in v1.0.0) and Keccak hashes.
- Elliptic curve operations over Weierstrass curves including ECDSA on secp256k1 and secp256r1 (new in v1.0.0).
- Optimal Ate pairing on curves including BN254 and BLS12-381.
- Int256 and modular arithmetic over arbitrary moduli.
- STARK recursion.

In addition to this feature-rich set of defaults shipping with OpenVM, developers can customize OpenVM for their use cases by writing new program-specific VM extensions and integrating them seamlessly using OpenVM’s modular architecture. We applied this approach to optimizing recursion for the v1.0.0 release, with substantial performance benefits (more below!).

In conjunction with the release, we have formalized the specification for OpenVM in a new whitepaper and more detailed specifications, which together describe the behavior of the toolchain, transpiler, and ZK circuits underlying OpenVM. They also give soundness and security proofs for the underlying proof systems and describe the security goals of the system.

Performance Updates

The v1.0.0 release can prove Ethereum mainnet blocks for ~$0.0015 per transaction and in under 3 minutes on CPU machines. This represents a 5x+ performance improvement over our December 2024 v0.1 release and was enabled by optimizations across the stack, most notably with a blazing-fast new recursion system using program-specific circuits and direct hinting and substantial improvements to execution and tracegen.

To evaluate performance, we integrated the default VM extensions shipping with OpenVM into Revm and Reth and generated proofs for the state transition function for mainnet Ethereum blocks on CPU machines. We generated both STARK proofs and smaller proofs efficiently verifiable on the EVM and measured proving times on a single machine (serial) and multiple machines (parallel) as well as the cost per transaction.

On the same set of mainnet blocks we evaluated on the v0.1 release in December, OpenVM v1.0.0 improves by over 5x on both cost and latency, with proving costs under $0.001 per transaction. Proving latency is under 10 minutes on a single machine for both STARK and EVM proofs, dropping to under 3 minutes for EVM proofs and under 70 seconds for STARK proofs on multiple machines.

m8g.24xlarge on AWS, details here

We also generated proofs for a more recent 1000 block range of mainnet blocks with block numbers between 22,000,000 and 22,000,999. OpenVM has a higher average proving cost of $0.0015 per transaction over this sample due to higher average gas usage per transaction, with single machine proving still under 10 minutes and multi-machine proving staying under 70 seconds for STARK proofs and 3 minutes for EVM proofs.

m8g.24xlarge on AWS, details here

These benchmarks are reproducible via our benchmark repo here. We are encouraged by our progress on performance and are excited to keep shipping improvements – more here soon!

What’s Next

With this release, we are excited to see OpenVM used in live production environments including Scroll’s upcoming mainnet upgrade. In conjunction with this, Axiom is launching the hosted Axiom Proving API to support developers using OpenVM with deployment and ZK proof generation services.

In the coming months, we will continue development of OpenVM to add new proof system backends, new prover modalities (client-side, mobile, HW accelerated), and further improve proving performance. We remain committed to the modular and open development philosophy behind OpenVM and have started collaborations with several new ecosystem teams since the previous December release. If you are interested in contributing or a deeper collaboration, reach out on Telegram or X.

In the meantime, learn more and try out OpenVM today by checking out:

Developer Quickstart: A developer-focused guide to proving your first Rust program with OpenVM.
Developer Book: A guide for using OpenVM to prove arbitrary code execution in Rust and for customizing OpenVM by adding program-specific VM extensions.
Whitepaper and Specifications: A formal specification for OpenVM including details on the proof system, no-CPU architecture, continuations design, and soundness analysis.

As always, you can find our open-source code on Github – see you there!

Introducing OpenVM

2026-02-10T00:04:46+00:00

We are excited to announce OpenVM, a novel open-source zkVM framework prioritizing modularity and extensibility across the ISA, toolchain, ZK circuits, and proof system. OpenVM is built for the future of zkVMs, where developers seek customization and extensibility without making tradeoffs on maintainability or performance. The modular OpenVM design addresses these needs by allowing developers to add custom opcodes, circuits, and proof systems, all within the same framework.

OpenVM was initiated by Axiom, Scroll, and individual collaborators including Max Gillett. With this release, we are looking for additional contributors to add support for different proof systems, proving environments, and frontends. We believe an open ecosystem with multiple independent teams collaborating on the same modular framework will provide developers the most future-proof and adaptable zkVM solution amongst continuous innovations in proof system and zkVM design.

The v0.1 release of OpenVM, available today under MIT license, includes a Rust frontend, proving of arbitrary length programs via aggregation, and efficient onchain verification. The initial set of extensions includes RISC-V via RV32IM, proof aggregation, ECDSA, pairings on BN254 and BLS12-381, int256 and modular arithmetic, and hashes including Keccak and Poseidon2. Developers can integrate their own custom VM extensions by simply importing the OpenVM crates, no repo forks required.

To try out OpenVM, check out the developer book and our code on Github. If you’d like to chat about using or contributing to OpenVM, join the developer Telegram.

Why OpenVM

Existing zkVM solutions are monolithic and developed by single entities, meaning developers face lock-in to vertically integrated stacks and incur the burden of maintaining upstream repo forks to add custom functionality. OpenVM addresses these issues by introducing a new zkVM design paradigm with modularity at each level of the stack, summarized below. A detailed OpenVM design spec is available at the contributor docs.

OpenVM supports arbitrary ISAs through VM extensions, which are groups of opcodes interoperating over common memory spaces. All functionality, including RISC-V and proof aggregation support, is implemented through extensions and can be accessed by developers through a Rust frontend.
OpenVM introduces a novel no-CPU zkVM design where the execution trace is not materialized in any single ZK circuit. This enables developers to integrate custom extensions without forking or modifying the core OpenVM libraries, minimizing security surface area and maintenance overhead.
The modular OpenVM design enables the use of different proof systems for different pieces of the system, enabling developers to experiment with and benefit from proof system improvements without rebuilding the entire zkVM stack.

The end result is that ZK teams building on OpenVM can customize where necessary while still benefiting from zkVM innovations across the stack from a community of different teams. We believe this approach will provide application developers with the most future-proof and performant zkVM solution.

What’s Available Today

The initial v0.1 release of OpenVM is MIT licensed and available today on Github with a user guide at the developer book. It supports:

Proving arbitrary Rust code via compilation to RISC-V, continuations, and onchain verification. Both no-std and std Rust programs are supported, with the exclusion of OS-dependent functionality like randomness and file IO.
A feature-rich initial set of VM extensions, including RV32IM, a recursion-focused extension for Baby Bear arithmetic, int256 arithmetic and modular arithmetic over user-specified moduli, hashes including Keccak and Poseidon2, and elliptic curve operations on arbitrary curves including ECDSA on Secp256k1 and optimal Ate pairing on BN254 and BLS12-381.
Full support for arbitrary developer-created VM extensions via the same Rust frontend via compilation to custom RISC-V assembly. This includes the ability to execute and prove unbounded programs involving custom user-defined extensions onchain.

To demonstrate what is currently possible with OpenVM, we integrated the initial VM extensions into revm and reth and generated onchain proofs of the state transition function for mainnet Ethereum blocks. Indicative benchmarks for a representative set of blocks as of the v0.1 release in December 2024 are shown below:

m7a.48xlarge on AWS, details here

Additional features are in development across the stack, including optimized aggregation, usage of different proof systems, and hardware acceleration. We expect significant reductions in cost and latency as we ship these improvements.

What’s Next

In the coming months, we plan to extend the OpenVM framework and apply it to different use cases:

Axiom will continue proof system and zkVM development for OpenVM and will release ZK-enabled products building upon and supporting OpenVM. If you are interested in deeper support while using or customizing OpenVM for your project, get in touch here.
Scroll will continue proof system and zkVM development for OpenVM and will use OpenVM in its upcoming zkVM-powered upgrade. Scroll will also explore a new GKR-based zkVM design, Ceno, to be integrated into the OpenVM framework with a common developer frontend.
Other contributors are adding features to OpenVM to target use cases in client-side proving, privacy, and blockchain scalability.

We believe the most flexible, performant, and secure zkVM framework will come from a diverse set of contributors using a shared modular infrastructure for different use cases, and we are excited to work with new contributors with this first public release, either as individuals or teams. If you’d like to contribute to and benefit from adapting OpenVM for your use case, come chat with us on Telegram.

If you want to dive right in, check out:

Quickstart guide: A step-by-step introduction to proving your first Rust program using OpenVM.
Developer book: A guide for using the full OpenVM framework to prove arbitrary code execution in zkVM and how to customize OpenVM for your needs by integrating a custom extension.
OpenVM design spec: Detailed explanations of novel design components in OpenVM including our modular transpiler, no-CPU architecture, variable word size support, and optimized continuations design.

We’re excited to see what extensions or applications you will build with OpenVM!