SP1 vs RISC Zero vs Jolt vs OpenVM: choosing a zkVM in 2026

As of October 16, 2026, the four main Rust zkVMs are at SP1 v6.9.0, RISC Zero zkVM 3.0 (current docs version), OpenVM v2.0.2 and Jolt's alpha main branch, which now has a lattice-based Akita backend next to its default Dory backend. If your team needs to prove a Rust function, compare the four on the table below, then run each project's minimal flow before you commit to one.

This guide is for Rust developers who know what a proof is but have not shipped a zkVM yet. By the end you will have a comparison table and four short "prove a Rust function" flows. Each one names the version it applies to and comes from that project's own docs.

Prerequisites: rustup on Linux or macOS, plus each project's CLI: cargo-prove for SP1, cargo-risczero for RISC Zero, the jolt binary for Jolt, and cargo-openvm for OpenVM. OpenVM v2.0.2 builds its CLI with Rust 1.91 and uses nightly-2026-01-18 for guest builds. Jolt installs from a nightly toolchain. Expect long build times and high RAM use for real proofs.

The comparison

Performance claims, attributed

No project publishes numbers you can compare directly, and every figure below comes from the vendor:

• SP1: Succinct says SP1 "consistently delivers state-of-the-art performance on industry-standard benchmarks" and that Hypercube brings "significant performance improvements". The intro page gives no specific numbers.
• Jolt: the JoltBook calls Jolt "fast (state-of-the-art performance on CPU)". LayerZero's Akita launch material says Akita proofs are 65-80 KB, compared with 200 KB or more for typical hash-based post-quantum systems. It also claims 2-3x faster proving than current Jolt and about 2x lower memory use.
• OpenVM: Axiom says its open-source GPU prover proves Ethereum mainnet blocks "for under $0.001 per transaction".
• RISC Zero: the 3.0 introduction pages make no headline performance claim, so none is quoted here.

Treat all of these as marketing until you measure your own guest program on your own hardware.

Prove a Rust function: four minimal flows

1. SP1 (v6.9.0)

The SP1 quickstart creates a project with two crates: program holds the code that is proven inside the zkVM, and script holds the proof generation and verification code.

cargo prove new --bare fibonacci
cd fibonacci
# guest code: program/src/main.rs
# proving code: script/
cd script
RUST_LOG=info cargo run --release -- --prove

The guest's src/main.rs must start with the two lines the SP1 setup page requires. Inputs are read from the host and outputs are committed as public values:

#![no_main]
sp1_zkvm::entrypoint!(main);

pub fn main() {
    let n = sp1_zkvm::io::read::<u32>();
    // ... compute on n ...
    sp1_zkvm::io::commit(&n);
}

The quickstart says that for non-trivial programs or production benchmarking it "highly recommend[s]" proving on the Succinct Prover Network. Local proving works for small programs and for development.

2. RISC Zero (zkVM 3.0 docs)

Install the toolchain with rzup, then create a project from the default template:

curl -L https://risczero.com/install | bash
rzup install
cargo risczero new my_project
cd my_project
RISC0_DEV_MODE=1 cargo run --release   # fast, fake receipts for iteration
cargo run --release                    # real proof

The template splits the project into a host (src/main.rs) and a guest (methods/guest/src/main.rs). The guest reads input and commits output to the journal:

use risc0_zkvm::guest::env;

fn main() {
    let input: u32 = env::read();
    env::commit(&input);
}

The host builds an executor environment, proves, and checks the receipt against the guest's image ID:

let env = ExecutorEnv::builder().write(&input).unwrap().build().unwrap();
let prover = default_prover();
let prove_info = prover.prove(env, METHOD_ELF).unwrap();
let receipt = prove_info.receipt;
let output: u32 = receipt.journal.decode().unwrap();
receipt.verify(METHOD_ID).unwrap();

The template generates the METHOD_ELF and METHOD_ID constants from your guest's name.

3. Jolt (main branch, alpha)

Jolt has the shortest path. You mark a normal Rust function as provable, and the macro generates the host-side prove and verify functions.

cargo +nightly install --git https://github.com/a16z/jolt --force --bins jolt
jolt new <PROJECT_NAME>
cd <PROJECT_NAME>
cargo run --release

The template's guest is a Fibonacci function:

#[jolt::provable]
fn fib(n: u32) -> u128 {
    let mut a: u128 = 0;
    let mut b: u128 = 1;
    let mut sum: u128;
    for _ in 1..n {
        sum = a + b;
        a = b;
        b = sum;
    }
    b
}

cargo run --release compiles the guest, runs preprocessing, then proves and verifies the 50th Fibonacci number. You only need to run preprocessing once per program and can reuse it for many proofs. To pick a backend, see the quickstart's "choosing a commitment backend" section. Dory is the default. Zero-knowledge proofs on Dory use BlindFold and are turned on with the zk Cargo feature.

4. OpenVM (v2.0.2)

Install the CLI. This is the CUDA build from the install page; the same page also lists a CPU-only install and an experimental tco build:

cargo +1.91 install --locked --git https://github.com/openvm-org/openvm.git --tag v2.0.2 --features cuda cargo-openvm
cargo openvm --version

Then follow the quickstart:

cargo openvm init fibonacci
cd fibonacci
cargo openvm run --input "0x010A00000000000000"        # execute only, no proof
cargo openvm keygen                                     # writes ./target/openvm/app.pk and app.vk
cargo openvm prove app --input "0x010A00000000000000"   # writes ./fibonacci.app.proof
cargo openvm verify app

The input is n = 10u64, little-endian, padded to exactly 8 bytes. The 0x01 prefix marks it as raw bytes. The guest reads it with io::read. For a single aggregated proof or an EVM proof, run cargo openvm setup --evm once, then cargo openvm prove evm and cargo openvm verify evm.

How to choose

1. Need C or C++ guests, or no prover hardware of your own? Start with SP1. It is the only one of the four that lists C and C++, and its docs steer you to a hosted prover network.
2. Want a long-established Rust API and a rustc target that is in upstream Rust? RISC Zero's riscv32im-risc0-zkvm-elf target is in the official rustc platform list, and its dev mode makes the edit-run loop fast.
3. Need post-quantum proofs without large hash-based proofs, and can accept alpha software? Try Jolt with the Akita backend. Recursion and an on-chain verifier are not done yet.
4. Need custom instructions (hashes, pairings, big-int math) or audited, production-recommended code you can host yourself? OpenVM's no-CPU design adds custom chips "without forking or modifying the core architecture". It ships extensions for Keccak-256, SHA2-256, Int256, modular arithmetic, elliptic curves and BN254/BLS12-381 pairings.

Pitfalls and troubleshooting

• Post-quantum stops at the wrapper. All four can produce a hash-based or lattice-based inner proof. EVM verification adds an elliptic-curve step: SP1's STARK-to-SNARK wrapper, RISC Zero's Groth16 receipts, OpenVM's halo2 EVM proof, or Jolt's default Dory backend. If you need post-quantum guarantees end to end, verify the inner proof directly.
• Docs that lag behind the code. SP1's "What is a zkVM?" page still describes STARKs with FRI over the Baby Bear field, while the SP1 introduction says V6 uses the multilinear Hypercube system. OpenVM's quickstart still shows tag = "v1.5.0" in the generated dependency, while the install page uses v2.0.2. Pin the guest crate and the CLI to the same release.
• Fake receipts in production. RISC0_DEV_MODE=1 skips real proving. Make sure CI and release builds never set it.
• Memory. OpenVM's SDK docs warn that cargo openvm setup --evm needs about 70 GB of memory. CUDA EVM proving also uses much more GPU memory than prove app or prove stark. SP1 points heavy jobs to its network for the same reason.
• Nightly toolchains. Jolt installs with cargo +nightly, and OpenVM guest builds pin nightly-2026-01-18. Pin these toolchains in rust-toolchain.toml so CI does not break when a new nightly ships.
• Jolt API changes. The JoltBook marks Jolt as alpha and lists streaming, recursion and an on-chain verifier as roadmap items. Expect breaking changes between commits and pin a git revision.

FAQ

Which Rust zkVM is post-quantum secure?

The core proofs of SP1, RISC Zero and OpenVM are hash-based STARK-style proofs, and Jolt's Akita backend is lattice-based. Jolt's default Dory backend is not post-quantum. Neither are the elliptic-curve SNARK wrappers that all four projects use for cheap EVM verification.

Can I prove a Rust program without my own GPU?

Yes. SP1 recommends the Succinct Prover Network for non-trivial programs, and RISC Zero documents remote proving options in its 3.0 "Generating Proofs" section. The OpenVM and Jolt docs describe proving on your own machines: CPU for both, plus CUDA GPUs for OpenVM.

Which zkVM is production-ready in 2026?

OpenVM says v2.0.0 and later are recommended for production after a zkSecurity audit. SP1's docs call it feature-complete and audited, and RISC Zero has shipped stable major versions through 3.0. Jolt calls itself alpha and still lists recursion and an on-chain verifier on its roadmap.