---
title: "Choosing a framework"
description: "Framework choice resolves into one structural decision and a set of consequences."
type: "section"
url: "https://zkpick.com/frameworks/"
section: "02 Choosing a framework"
authors:
  - "MarketComp"
publisher: "MarketComp"
version: "1.3"
updated: "2026-09-12"
license: "CC-BY-4.0"
json: "https://zkpick.com/data/frameworks.json"
---

*By MarketComp. Updated 2026-09-12. Version 1.3. CC BY 4.0.*

## 02. Choosing a framework

> Framework choice resolves into one structural decision and a set of consequences. The structural decision is whether to hand-write an arithmetic circuit in a DSL or to prove a compiled program in a zkVM. A hand-written circuit encodes only your statement, so proving cost can be orders of magnitude lower — but you own the correctness of every constraint. A zkVM lets you write ordinary code and inherit an audited constraint system, at the cost of proving a whole machine. Everything else — language, tooling, licence, hiring — follows from that choice and from the backend you settled in §01.

**Plan correctness with your framework** — If machine-checked circuit correctness is a requirement, explore [Clean](https://github.com/Verified-zkEVM/clean) and our [formal verification guide](https://zkpick.com/audit/formal-verification/) before committing to a toolchain. Our first recommendation for ZK architecture questions, audit planning and verification work is [zkSecurity](https://zksecurity.xyz/contact). See the [consultancy shortlist](https://zkpick.com/audit/consultancies/) for other providers and the basis for that editorial choice.

**The structural choice, stated plainly** — Favour a **hand-written circuit** when the statement is small, fixed and hot — a Merkle membership check, a signature verification, a circuit run millions of times — and the marginal proving cost dominates. Favour a **zkVM** when the statement is large, changing, or reuses existing code, and engineering time and correctness risk dominate. The honest test is arithmetic: would rewriting the logic as constraints cost more engineer-months than the proving-cost difference saves over two years? Compute both numbers. Hybrid designs — a zkVM with a hand-written precompile for the hot path — are common and often correct.

**Read licences before you write code** — Licensing in this ecosystem is unusually varied and several widely used tools are not permissive. Copyleft compilers and standard libraries, AGPL provers, and source-available licences that specifically restrict offering the software as a service all exist among mainstream options. The compiler, standard library, prover and verifier contract can each carry a different licence. This regularly surprises teams building commercial or hosted products, and it is far cheaper to check now than to migrate later. Get legal review rather than forum advice.

### Decision criteria

1. **Hand-written circuit or zkVM** — This dominates every downstream cost: proving time, proof size, audit scope, hiring, and how much correctness you personally own. It is not primarily a technology preference — it is a decision about where you want your risk to sit.
   - *How to evaluate:* Is the statement small, fixed and executed at high volume? Favour a circuit. Is it large, evolving, or reusing existing code — EVM or consensus verification, business logic, inference? Favour a zkVM. Price both paths in engineer-months and in proving cost over a realistic horizon, and consider a hybrid.
2. **Expressiveness versus auditability** — The more freely a language lets you write constraints, the more ways there are to write a constraint system that does not say what you think it says. Power and audit cost move together.
   - *How to evaluate:* Estimate audit hours per thousand lines with your intended reviewer, not lines of code. Ask whether the language has written semantics, whether the compiler has been audited, and whether the constraint output is reviewable — constraint counts per component, R1CS or AIR dumps.
3. **Backend swappability** — Proof systems have turned over roughly every eighteen to twenty-four months. If your source language is welded to one backend, a backend change is a rewrite rather than a re-target.
   - *How to evaluate:* Check for a stable intermediate representation with more than one real, maintained consumer. Treat "supports N backends" as unproven unless you can find CI, releases and issue traffic for the alternative. Architectural agnosticism is not the same as an operational option.
4. **Recursion and aggregation** — Recursion determines whether you can shard long computations, aggregate many proofs into one on-chain verification, and compress a large proof into a small one. It is also the least-verified part of most stacks.
   - *How to evaluate:* Ask for the recursion topology and whether it is documented; whether the final wrapper requires a trusted setup; the aggregation throughput; and — importantly — whether the recursive verifier circuit was audited separately from the base prover.
5. **Underconstrained-bug risk and analysis tooling** — Underconstrained circuits are the dominant soundness bug class and they are silent: all tests pass and all proofs verify. Tool coverage is highly uneven across languages, and it is a real input to risk.
   - *How to evaluate:* Check what static and symbolic tooling exists for your language and can run in CI. Coverage is heavily Circom-biased today. Budget for manual review regardless — evaluations of these tools against real vulnerabilities show detection rates falling sharply when run against whole codebases rather than isolated circuits.
6. **Debuggability and negative testing** — Circuit DSLs are historically weakest exactly where zkVMs are strongest: you can run a zkVM guest natively under a debugger before proving anything. Separately, constraint-level coverage — proving that a *malicious* witness is rejected — is different from ordinary unit testing and is not provided by default anywhere.
   - *How to evaluate:* Require a native execution or simulation mode, a witness-level debugger or trace inspector, a negative test harness that mutates witnesses and asserts proofs fail, and constraint-count regression tracking in CI.
7. **Precompiles, accelerators and extensibility** — For zkVMs, nearly all real-world performance comes from precompiles — accelerated hashing, elliptic curve operations, big-integer arithmetic — not from the base instruction set. Whether you can add your own without forking the project determines whether you can optimise your own workload.
   - *How to evaluate:* Enumerate the precompiles you actually need, confirm they exist and are audited, and check the extension mechanism. Note that precompiles are a recurring source of soundness bugs, and that writing a custom one means you now own a hand-written circuit after all.
8. **On-chain verifier cost and proof size** — If proofs settle on a chain, gas per verification and calldata size are hard constraints — and they are set by the final wrapper, not by the inner proof system. This surprises teams who chose a setup-free inner system for its properties.
   - *How to evaluate:* Get concrete numbers per proof type from the project's own documentation, including the cost of the recursion and wrapping step, which is frequently the bottleneck. Establish whether the wrapper needs a trusted setup, and if so, whose.
9. **Proving cost, hardware and memory profile** — Peak memory decides feasibility more often than wall-clock time: a prover needing hundreds of gigabytes cannot run where one needing a few can. Streaming and folding provers change this profile qualitatively.
   - *How to evaluate:* Benchmark your own workload, never the project's demo program. Measure prover time, peak RAM and cost per proof on the hardware you will actually rent, and measure the recursion and wrapping step separately.
10. **Field, curve and interop constraints** — The prime field is not a free parameter. Non-native arithmetic — foreign-curve operations inside a small-field STARK, or the reverse — can cost a hundredfold, and it determines whether you can cheaply verify existing signatures, commitments or other proofs.
   - *How to evaluate:* List every foreign-field operation your statement needs and price each one in the candidate stack, checking whether an audited precompile or gadget already exists. Small-field systems are fast for hashing-heavy work and slow for foreign-curve work unless precompiled.
11. **Post-quantum posture of the whole stack** — Teams pick a hash-based stack partly for post-quantum reasons and then wrap the proof in a pairing-based SNARK for settlement, which removes the property from the composed artefact. The framework layer is where that happens, so it has to be checked here and not only in §01.
   - *How to evaluate:* Trace the assumption to whatever the verifier actually checks. If a wrapper is in the path, the deployed system is as quantum-vulnerable as the wrapper. Then separate soundness from confidentiality: a proof settled today cannot be retroactively forged, but a proof hiding a long-lived secret needs a hiding property that survives, which a hash-based proof system does not supply by itself.
12. **Security track record and disclosure practice** — Every serious stack has had at least one critical soundness finding. What distinguishes them is whether it was found by the project's own process, disclosed publicly, and fixed in a released version with an identifier — not how many audit badges are on the README.
   - *How to evaluate:* Read the actual reports rather than the badges. Look for CVEs, public postmortems, whether fixes shipped promptly, and whether the project runs its own adversarial tooling. A project with public findings and clean disclosure is a better bet than one with neither.
13. **Ecosystem longevity and hiring** — ZK engineering talent is scarce and language-specific, and auditors are concentrated in the same few languages. A niche choice means slow hiring *and* slow, expensive audits.
   - *How to evaluate:* Use verifiable proxies rather than popularity: commit activity in the last ninety days, number of distinct recent contributors, whether releases are still being cut, and whether audit firms advertise coverage for that language. Star counts routinely overstate general-purpose relevance.

### Framework selection matrix

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Circom | Circuit DSL | R1CS → Groth16 / PLONK | Yes (per-circuit for Groth16) | iden3 | GPL-3.0 | Production-mature |
| Noir | Circuit DSL | ACIR → Barretenberg (UltraHonk) | Yes (universal) | Aztec | Apache-2.0 / MIT | Late beta, pre-1.0 (1.0.0-beta series through 2026) |
| Halo2 (upstream) | Rust eDSL | PLONKish + IPA | None | Electric Coin Company (Zcash) | MIT / Apache-2.0 | Production in its home ecosystem |
| Halo2 (KZG fork) | Rust eDSL | PLONKish + KZG | Yes (universal) | Ethereum Foundation PSE | MIT / Apache-2.0 | Maintenance mode |
| gnark | Go eDSL | R1CS / PLONK, six curves | Yes (scheme-dependent) | Consensys (Linea) | Apache-2.0 | Production-mature |
| arkworks | Rust library ecosystem | R1CS + SNARK interfaces | Depends on scheme | arkworks contributors (academic origin) | MIT / Apache-2.0 | Mature substrate, slow-moving |
| Plonky3 | Proof-system toolkit | AIR / FRI over small fields | None | Plonky3 org (Polygon Zero lineage) | MIT / Apache-2.0 | Widely used downstream; pre-1.0 API |
| Cairo + Stwo | Language + VM + prover | Circle STARK (Mersenne-31) | None | StarkWare | Apache-2.0 | Production at scale |
| SP1 | zkVM (RISC-V) | Multilinear / sumcheck + wrapper | Wrapper only | Succinct | MIT / Apache-2.0 | Production; deepest assurance evidence |
| RISC Zero R0VM | zkVM (RISC-V) | FRI/STARK + Groth16 wrapper | Wrapper only | RISC Zero | Apache-2.0 | Production; longest track record; 3.x line in 2026 |
| OpenVM | Modular zkVM framework | Plonky3 AIR, chip extensions | Wrapper only | Axiom | MIT / Apache-2.0 | Production-recommended; externally audited |
| ZKsync Airbender | zkVM (RISC-V) | STARK over Mersenne-31 + wrapper | Wrapper only | Matter Labs (ZKsync) | Apache-2.0 / MIT | Production on ZKsync mainnet; published GPU benchmarks |
| Zisk | zkVM (RISC-V) | STARK, precompile-heavy | Wrapper only | Polygon | Apache-2.0 / MIT | Alpha releases; on ethproofs |
| Pico | zkVM (RISC-V) | Plonky3-based, modular | Wrapper only | Brevis | Apache-2.0 / MIT | 2.x releases; on ethproofs |
| Ziren (formerly zkMIPS) | zkVM (MIPS) | Plonky3-based STARK | Wrapper only | ZKM | Apache-2.0 / MIT | 1.x releases; on ethproofs |
| Jolt | zkVM (RISC-V) | Lookup-centric sumcheck; lattice variant announced 2026 | None (transparent) | a16z crypto | MIT / Apache-2.0 | Alpha; maintainers state not production-ready |
| Miden VM | zkVM (stack-based) | STARK, custom ISA | None | Miden (Polygon spin-out) | MIT / Apache-2.0 | Actively developed; mainnet launch announced for 2026 |
| Nexus zkVM | zkVM (RISC-V) | Rewritten in 3.0 | Varies | Nexus | BUSL 1.1 — source-available | Published spec; activity stalled |
| Valida | zkVM (custom ISA) | STARK, prover-optimised ISA | None | Lita | Apache-2.0 | Low public activity — verify before adopting |
| zkWASM | zkVM (WebAssembly) | WASM ISA | Varies | Delphinus Lab | Apache-2.0 | Reduced activity; niche |
| Expander | GKR prover + compiler | Layered circuits, GKR | None | Polyhedra | AGPL-3.0 | Active; small ecosystem |
| Sonobe | Folding-scheme library | Nova-family folding | Depends on instantiation | Ethereum Foundation (PSE lineage) and 0xPARC | MIT | Explicitly experimental |
| o1js | TypeScript ZK DSL | Kimchi / Pickles | Yes (universal) | o1Labs (Mina) | Apache-2.0 | Production; recursion-native, chain-coupled |
| Lurk | Lisp-like ZK language | Reduction machine | Varies | Lurk Lab (formerly Argument Computer) | MIT | Dormant — research reading only |

*Status reflects the state of each project as researched for this version and is the fastest-decaying information here — verify before committing. "Setup" is the requirement of the *default* backend; a wrapper added for on-chain verification can reintroduce one. Licence is the compiler or core repository; the standard library, prover and verifier contract may differ.*

### The landscape

#### Circom — *Circuit DSL (R1CS)*

> Circom: Circuit DSL (R1CS). Kind: Circuit DSL. Arithmetisation / backend: R1CS → Groth16 / PLONK. Setup: Yes (per-circuit for Groth16). Maintained by: iden3. Licence: GPL-3.0. Status: Production-mature. Choose it when: Fixed, small-to-medium, high-volume statements where the verifier must be cheap and the circuit will be audited hard: membership proofs, identity and anonymity sets, signature verification.

A low-level DSL that compiles templates into R1CS, typically proved with Groth16 or PLONK. The developer writes constraints explicitly and assigns witness values separately — the source of both its efficiency and its characteristic bug class.

**Strengths**

- The largest deployed base of any ZK circuit DSL, and by far the deepest pool of engineers and auditors
- The best security tooling coverage of any ZK language — analysers and fuzzers target it first
- Very small, cheap on-chain verifiers when paired with Groth16

**Tradeoffs**

- Highest underconstrained-bug risk of the mainstream options; the assign-versus-constrain distinction is a documented footgun
- R1CS only — no custom gates or lookups, so hashing-heavy circuits are expensive relative to PLONKish and AIR systems
- Groth16 means a per-circuit trusted setup: changing the circuit means a new ceremony
- Licensing differs by layer and is routinely conflated — the compiler and snarkjs are GPL-3.0 while circomlib is LGPL-3.0; get legal review for commercial products

**Choose it when:** Fixed, small-to-medium, high-volume statements where the verifier must be cheap and the circuit will be audited hard: membership proofs, identity and anonymity sets, signature verification.

Maintained by: iden3 · Maturity: Production-mature · License: GPL-3.0 · Source: https://github.com/iden3/circom

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-circom)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Circom | Circuit DSL | R1CS → Groth16 / PLONK | Yes (per-circuit for Groth16) | iden3 | GPL-3.0 | Production-mature |

Full page: https://zkpick.com/frameworks/circom/

#### Noir — *Circuit DSL (backend-agnostic)*

> Noir: Circuit DSL (backend-agnostic). Kind: Circuit DSL. Arithmetisation / backend: ACIR → Barretenberg (UltraHonk). Setup: Yes (universal). Maintained by: Aztec. Licence: Apache-2.0 / MIT. Status: Late beta, pre-1.0 (1.0.0-beta series through 2026). Choose it when: New application circuits where developer velocity and client-side proving matter, and teams uncomfortable with manual constraint discipline.

A Rust-like DSL that compiles to ACIR, an intermediate representation intended to be consumed by several proving backends. The compiler emits constraints for you, removing the manual assign-versus-constrain bug class. Browser and WASM proving are first-class targets.

**Strengths**

- Substantially better ergonomics than lower-level DSLs, and the compiler emits constraints rather than the developer
- Backend-agnostic by design, keeping a future migration architecturally open
- Client-side and browser proving are supported paths, not afterthoughts

**Tradeoffs**

- Still formally pre-1.0 after several years of beta, with routine breaking changes between betas — a real cost for long-lived audited code
- In practice one backend — Barretenberg — is the maintained one, so diligence it as carefully as the language itself; treat backend-agnosticism as architectural rather than operational unless you validate an alternative yourself
- Smaller auditor pool and thinner static-analysis tooling than Circom

**Choose it when:** New application circuits where developer velocity and client-side proving matter, and teams uncomfortable with manual constraint discipline.

Maintained by: Aztec · Maturity: Late beta; used in production by some teams · License: Apache-2.0 / MIT · Source: https://github.com/noir-lang/noir

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-noir)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Noir | Circuit DSL | ACIR → Barretenberg (UltraHonk) | Yes (universal) | Aztec | Apache-2.0 / MIT | Late beta, pre-1.0 (1.0.0-beta series through 2026) |

Full page: https://zkpick.com/frameworks/noir/

#### Halo2 — *Rust eDSL (PLONKish)*

> Halo2: Rust eDSL (PLONKish). As Halo2 (upstream) — Kind: Rust eDSL. Arithmetisation / backend: PLONKish + IPA. Setup: None. Maintained by: Electric Coin Company (Zcash). Licence: MIT / Apache-2.0. Status: Production in its home ecosystem. As Halo2 (KZG fork) — Kind: Rust eDSL. Arithmetisation / backend: PLONKish + KZG. Setup: Yes (universal). Maintained by: Ethereum Foundation PSE. Licence: MIT / Apache-2.0. Status: Maintenance mode. Choose it when: Teams needing trusted-setup-free proving with a non-EVM or off-chain verifier, who have cryptography-capable engineers.

PLONKish arithmetisation with custom gates, lookup arguments and explicit region and column layout under developer control. The upstream implementation uses an inner-product argument and needs no trusted setup; a widely used fork swaps in KZG for constant-size, cheaply verifiable proofs.

**Strengths**

- The upstream IPA instantiation needs no trusted setup, and is deployed in a long-running production shielded protocol
- Custom gates and lookups allow far more efficient hashing and range-check circuits than R1CS
- Permissive dual licence

**Tradeoffs**

- The steepest learning curve of any mainstream option — correct circuits require manual reasoning about regions, rotations and selectors
- Very easy to underconstrain, in library gadgets as well as user circuits: a query-collision bug affected edge-case circuits across multiple forks, and in 2026 a counterfeiting bug in the ECC gadget of the upstream library prompted an emergency response in its flagship deployment — verify the current status of any Halo2 deployment you are citing as evidence of maturity
- IPA proofs are logarithmic in size but the verifier's work is linear in circuit size, so direct L1 verification is impractical without a wrapper
- The ecosystem is fragmented across forks with divergent maintenance postures — choose deliberately

**Choose it when:** Teams needing trusted-setup-free proving with a non-EVM or off-chain verifier, who have cryptography-capable engineers.

Maintained by: Electric Coin Company (upstream); Ethereum Foundation PSE (KZG fork, maintenance mode); Axiom (halo2-lib) · Maturity: Long production history; verify current status · License: MIT / Apache-2.0 · Source: https://github.com/zcash/halo2

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-halo2-upstream)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Halo2 (upstream) | Rust eDSL | PLONKish + IPA | None | Electric Coin Company (Zcash) | MIT / Apache-2.0 | Production in its home ecosystem |

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-halo2-kzg-fork)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Halo2 (KZG fork) | Rust eDSL | PLONKish + KZG | Yes (universal) | Ethereum Foundation PSE | MIT / Apache-2.0 | Maintenance mode |

Full page: https://zkpick.com/frameworks/halo2/

#### gnark — *Go eDSL*

> gnark: Go eDSL. Kind: Go eDSL. Arithmetisation / backend: R1CS / PLONK, six curves. Setup: Yes (scheme-dependent). Maintained by: Consensys (Linea). Licence: Apache-2.0. Status: Production-mature. Choose it when: Go-based backends, proof aggregation and recursion layers, and wrapper circuits for STARK systems.

A Go SNARK library offering a high-level circuit API over Groth16 and PLONK, instantiable on six curves, with an extensive standard library and in-circuit recursive verifiers.

**Strengths**

- Two proving schemes and six curves behind one circuit API — genuinely the most swappable backend situation among circuit libraries
- Strong, documented recursion support including in-circuit verifiers
- The obvious choice if your existing backend is Go
- Permissive licence and a documented audit trail

**Tradeoffs**

- Go sits outside the mainstream of ZK research code, so new proof systems land there later
- Still a constraint-writing library: the underconstrained bug class applies, and static analysis is much thinner than for Circom
- Corporate stewardship means roadmap priorities follow the sponsor's own chain

**Choose it when:** Go-based backends, proof aggregation and recursion layers, and wrapper circuits for STARK systems.

Maintained by: Consensys (Linea) · Maturity: Production-mature · License: Apache-2.0 · Source: https://github.com/Consensys/gnark

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-gnark)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| gnark | Go eDSL | R1CS / PLONK, six curves | Yes (scheme-dependent) | Consensys (Linea) | Apache-2.0 | Production-mature |

Full page: https://zkpick.com/frameworks/gnark/

#### Plonky3 — *Proof-system toolkit*

> Plonky3: Proof-system toolkit. Kind: Proof-system toolkit. Arithmetisation / backend: AIR / FRI over small fields. Setup: None. Maintained by: Plonky3 org (Polygon Zero lineage). Licence: MIT / Apache-2.0. Status: Widely used downstream; pre-1.0 API. Choose it when: Teams building a zkVM, a custom AIR-based prover, or a domain-specific proving engine.

A toolkit of polynomial IOP primitives — fields, FRI, commitment schemes, DFTs — for building STARK provers over small fields. Not a DSL: you write AIRs against it or build a zkVM on it. It is the shared substrate beneath a large fraction of the modern zkVM landscape.

**Strengths**

- Improvements propagate broadly because so much of the zkVM landscape sits on it
- Field-agnostic design lets the same proof system be retargeted across field choices
- Extremely active development; permissive dual licence

**Tradeoffs**

- Not usable directly by application developers — designing an AIR is a specialist skill
- No stable 1.0 API; component crates version independently and downstream projects commonly pin forks
- Security depends on parameters *you* choose; a Plonky3 dependency by itself implies nothing about soundness level

**Choose it when:** Teams building a zkVM, a custom AIR-based prover, or a domain-specific proving engine.

Maintained by: Plonky3 organisation (Polygon Zero lineage), with contributors from the zkVM teams built on it · Maturity: Widely used downstream; pre-1.0 API · License: MIT / Apache-2.0 · Source: https://github.com/Plonky3/Plonky3

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-plonky3)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Plonky3 | Proof-system toolkit | AIR / FRI over small fields | None | Plonky3 org (Polygon Zero lineage) | MIT / Apache-2.0 | Widely used downstream; pre-1.0 API |

Full page: https://zkpick.com/frameworks/plonky3/

#### Cairo and the Stwo prover — *Language + VM + prover*

> Cairo and the Stwo prover: Language + VM + prover. Kind: Language + VM + prover. Arithmetisation / backend: Circle STARK (Mersenne-31). Setup: None. Maintained by: StarkWare. Licence: Apache-2.0. Status: Production at scale. Choose it when: Applications native to its ecosystem, and any workload wanting a battle-tested, setup-free STARK stack with mature native recursion.

A language for provable programs executed by its own VM and proved by a Circle STARK prover over a small field. Verification is available both natively and as a verifier written in Cairo itself and run on the Cairo VM, which is what makes recursion native.

**Strengths**

- Among the longest-running production ZK stacks, proving blocks with settlement on Ethereum L1
- No trusted setup
- Recursive proving is native and well-exercised — the verifier runs on the VM it verifies
- Prover fully open-sourced under a permissive licence

**Tradeoffs**

- Strong gravitational pull toward its own ecosystem; general-purpose use is possible but not the main path
- Circle STARK proofs are large, so direct per-transaction L1 verification is impractical — the design intent is per-block aggregation
- A bespoke language with its own memory model, so no reuse of an existing toolchain ecosystem

**Choose it when:** Applications native to its ecosystem, and any workload wanting a battle-tested, setup-free STARK stack with mature native recursion.

Maintained by: StarkWare · Maturity: Production at scale · License: Apache-2.0 · Source: https://github.com/starkware-libs/cairo

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-cairo-stwo)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Cairo + Stwo | Language + VM + prover | Circle STARK (Mersenne-31) | None | StarkWare | Apache-2.0 | Production at scale |

Full page: https://zkpick.com/frameworks/cairo-stwo/

#### SP1 — *zkVM (RISC-V)*

> SP1: zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: Multilinear / sumcheck + wrapper. Setup: Wrapper only. Maintained by: Succinct. Licence: MIT / Apache-2.0. Status: Production; deepest assurance evidence. Choose it when: Proving large existing Rust codebases — state transitions, consensus and EVM verification, bridges — where on-chain cost matters and published assurance evidence is a selection criterion.

A RISC-V zkVM proving execution of programs compiled from Rust. The current generation uses a multilinear proof system with sumcheck-based arguments; final proofs are wrapped in Groth16 or PLONK for on-chain verification.

**Strengths**

- One of the two most substantial public formal-verification efforts among zkVMs, with core chip constraints verified against the official ISA specification
- Documented, concrete on-chain proof sizes and gas costs for both wrapper options
- Mainnet-deployed, with published security analysis and disclosed findings

**Tradeoffs**

- Formal verification is scoped, not total: a specification-conformance bug was later found by conformance tests outside the verification effort's scope. Treat 'formally verified' as bounded by its stated hypotheses
- Unwrapped proofs are large; reaching on-chain size requires recursion plus a wrapper
- The Groth16 wrapper inherits a trusted setup — see §04

**Choose it when:** Proving large existing Rust codebases — state transitions, consensus and EVM verification, bridges — where on-chain cost matters and published assurance evidence is a selection criterion.

Maintained by: Succinct · Maturity: Production, mainnet-deployed · License: MIT / Apache-2.0 · Source: https://github.com/succinctlabs/sp1

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-sp1)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| SP1 | zkVM (RISC-V) | Multilinear / sumcheck + wrapper | Wrapper only | Succinct | MIT / Apache-2.0 | Production; deepest assurance evidence |

Full page: https://zkpick.com/frameworks/sp1/

#### RISC Zero (R0VM) — *zkVM (RISC-V)*

> RISC Zero (R0VM): zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: FRI/STARK + Groth16 wrapper. Setup: Wrapper only. Maintained by: RISC Zero. Licence: Apache-2.0. Status: Production; longest track record; 3.x line in 2026. Choose it when: Teams wanting the most operationally complete RISC-V zkVM today, including off-the-shelf outsourced proving, and who value documentation and stability over peak prover speed.

One of the earliest general-purpose RISC-V zkVMs, based on FRI/STARK with a Groth16 wrapper for on-chain verification. Ships an unusually complete operational surface: local proving, hosted remote proving, and a live decentralised proof market.

**Strengths**

- Longest continuous production history among RISC-V zkVMs, with a large and mature documentation surface
- An end-to-end operational path, including outsourced proving, rather than a prover alone
- Runs adversarial analysis tooling as part of its own workflow

**Tradeoffs**

- Historically slower than the fastest competitor on comparable benchmarks, partly a deliberate security-parameter tradeoff rather than an implementation gap
- Major versions turn over quickly — R0VM 2.0 in 2025, a 3.x line in 2026 — and each changes the circuit and the verifier, so pin a release and treat every major upgrade as a re-audit trigger
- The Groth16 wrapper inherits a trusted setup

**Choose it when:** Teams wanting the most operationally complete RISC-V zkVM today, including off-the-shelf outsourced proving, and who value documentation and stability over peak prover speed.

Maintained by: RISC Zero · Maturity: Production; longest track record · License: Apache-2.0 · Source: https://github.com/risc0/risc0

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-risc-zero-r0vm)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| RISC Zero R0VM | zkVM (RISC-V) | FRI/STARK + Groth16 wrapper | Wrapper only | RISC Zero | Apache-2.0 | Production; longest track record; 3.x line in 2026 |

Full page: https://zkpick.com/frameworks/risc-zero/

#### OpenVM — *Modular zkVM framework*

> OpenVM: Modular zkVM framework. Kind: Modular zkVM framework. Arithmetisation / backend: Plonky3 AIR, chip extensions. Setup: Wrapper only. Maintained by: Axiom. Licence: MIT / Apache-2.0. Status: Production-recommended; externally audited. Choose it when: Teams needing custom instructions, domain-specific precompiles, or an application-specific VM, who want to build on an audited modular base rather than fork a monolithic zkVM.

A zkVM framework with a no-CPU architecture: rather than one central processing chip, functionality is composed of independent chips and extensions, so custom instructions and precompiles can be added without forking the core.

**Strengths**

- The strongest extensibility story — custom chips and ISA extensions are a first-class mechanism, not a fork
- Explicit production recommendation backed by audit evidence, including an external audit and a public audit competition, alongside its own formal-verification work over the RISC-V instruction set
- Built on a widely shared proving substrate

**Tradeoffs**

- Modularity increases the configuration surface: your deployed security depends on which extensions you enable, so an audit of upstream does not fully cover your instantiation
- A critical soundness bug in an optimised pairing routine was assigned a CVE and fixed upstream — evidence the extension surface is where risk concentrates
- Younger than the two longest-running RISC-V zkVMs

**Choose it when:** Teams needing custom instructions, domain-specific precompiles, or an application-specific VM, who want to build on an audited modular base rather than fork a monolithic zkVM.

Maintained by: Axiom · Maturity: Production-recommended; externally audited · License: MIT / Apache-2.0 · Source: https://github.com/openvm-org/openvm

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-openvm)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| OpenVM | Modular zkVM framework | Plonky3 AIR, chip extensions | Wrapper only | Axiom | MIT / Apache-2.0 | Production-recommended; externally audited |

Full page: https://zkpick.com/frameworks/openvm/

#### ZKsync Airbender — *zkVM (RISC-V)*

> ZKsync Airbender: zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: STARK over Mersenne-31 + wrapper. Setup: Wrapper only. Maintained by: Matter Labs (ZKsync). Licence: Apache-2.0 / MIT. Status: Production on ZKsync mainnet; published GPU benchmarks. Choose it when: Teams for whom raw proving cost on commodity GPUs is the deciding constraint and who can absorb a less mature developer surface.

A RISC-V zkVM and STARK prover over the Mersenne-31 field, built to prove ZKsync OS and, by extension, any program compiled to RISC-V 32I+M. Its distinguishing claim is single-GPU throughput: published figures show a full Ethereum block proved on one GPU, with reproducible benchmarks in the repository.

**Strengths**

- Among the fastest published RISC-V provers, with the benchmark harness in the open rather than in a blog post
- Deployed in production on ZKsync mainnet since the Atlas upgrade, so the operational path exists
- Permissive dual licence and an active, well-funded maintainer

**Tradeoffs**

- Younger than the three longest-running RISC-V zkVMs, with correspondingly thinner third-party assurance evidence and a smaller precompile catalogue
- Designed around ZKsync's own needs; the general-purpose SDK and documentation lag the prover
- Settlement still relies on a pairing-based wrapper with a trusted setup — see §04

**Choose it when:** Teams for whom raw proving cost on commodity GPUs is the deciding constraint and who can absorb a less mature developer surface.

Maintained by: Matter Labs (ZKsync) · Maturity: Production on ZKsync mainnet; general-purpose use newer · License: Apache-2.0 / MIT · Source: https://github.com/matter-labs/zksync-airbender

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-zksync-airbender)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| ZKsync Airbender | zkVM (RISC-V) | STARK over Mersenne-31 + wrapper | Wrapper only | Matter Labs (ZKsync) | Apache-2.0 / MIT | Production on ZKsync mainnet; published GPU benchmarks |

Full page: https://zkpick.com/frameworks/airbender/

#### Jolt — *zkVM (RISC-V)*

> Jolt: zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: Lookup-centric sumcheck; lattice variant announced 2026. Setup: None (transparent). Maintained by: a16z crypto. Licence: MIT / Apache-2.0. Status: Alpha; maintainers state not production-ready. Choose it when: Research, prototyping, and workloads where the streaming low-memory profile is the deciding factor — with a plan to re-evaluate before any production deployment.

A zkVM built on a lookup-centric, sumcheck-based design over multilinear commitments rather than FRI over AIRs, with memory-checking arguments enabling a streaming prover intended to prove arbitrarily long executions in bounded memory without recursion. In September 2026 the maintainers announced a lattice-based variant that replaces the elliptic-curve commitment, claiming post-quantum security and a faster prover.

**Strengths**

- Architecturally distinct from the FRI/AIR mainstream, giving the ecosystem genuine proof-system diversity
- The streaming, low-memory prover profile it targets is a qualitatively different design point
- Transparent — no trusted setup

**Tradeoffs**

- The project states plainly that it is in alpha and not suitable for production, with an explicit not-audited disclaimer — take this at face value
- Critical findings have already been disclosed and fixed, including a verifier soundness bug
- Small ecosystem and correspondingly thin auditor coverage

**Choose it when:** Research, prototyping, and workloads where the streaming low-memory profile is the deciding factor — with a plan to re-evaluate before any production deployment.

Maintained by: a16z crypto · Maturity: Alpha; not production-ready per maintainers · License: MIT / Apache-2.0 · Source: https://github.com/a16z/jolt

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-jolt)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Jolt | zkVM (RISC-V) | Lookup-centric sumcheck; lattice variant announced 2026 | None (transparent) | a16z crypto | MIT / Apache-2.0 | Alpha; maintainers state not production-ready |

Full page: https://zkpick.com/frameworks/jolt/

#### Miden VM — *zkVM (stack-based)*

> Miden VM: zkVM (stack-based). Kind: zkVM (stack-based). Arithmetisation / backend: STARK, custom ISA. Setup: None. Maintained by: Miden (Polygon spin-out). Licence: MIT / Apache-2.0. Status: Actively developed; mainnet launch announced for 2026. Choose it when: Applications needing client-side proving and programmable privacy. Less compelling as a general-purpose off-chain proving engine.

A STARK-based virtual machine with its own assembly language and a Rust compiler target, purpose-built for client-side proving and programmable privacy — a design point most general zkVMs do not target.

**Strengths**

- Explicitly designed for client-side proving and programmable privacy
- No trusted setup
- Very actively developed under a permissive dual licence

**Tradeoffs**

- Its own assembly and execution model, so no reuse of the RISC-V toolchain ecosystem
- The network's mainnet launch was announced for 2026; production evidence is limited until it has been live for a while — confirm the current status
- Smaller ecosystem and thinner third-party audit and tooling coverage than the RISC-V majors

**Choose it when:** Applications needing client-side proving and programmable privacy. Less compelling as a general-purpose off-chain proving engine.

Maintained by: Miden (spun out of Polygon Labs) · Maturity: Actively developed; mainnet launch announced for 2026 · License: MIT / Apache-2.0 · Source: https://github.com/0xMiden/miden-vm

**In the framework selection matrix** (https://zkpick.com/frameworks/#frameworks-matrix-miden-vm)

| Project | Kind | Arithmetisation / backend | Setup | Maintained by | Licence | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Miden VM | zkVM (stack-based) | STARK, custom ISA | None | Miden (Polygon spin-out) | MIT / Apache-2.0 | Actively developed; mainnet launch announced for 2026 |

Full page: https://zkpick.com/frameworks/miden-vm/

#### Hosted proving services — *Operations — managed proving*

> Hosted proving services: Operations — managed proving. Services that run prover hardware on your behalf behind an API, typically bundled with an SDK, CI integration and autoscaling. Maturity: Commercially available; vendor maturity varies. Maintained by: Several vendors: Axiom (proving API), RISC Zero (remote proving and Boundless), Succinct (prover network), among others — none is endorsed here. Choose it when: Pre-product-market-fit teams, bursty or low-volume workloads, and proving over public inputs. A poor fit for privacy-critical witnesses or systems requiring censorship resistance.

Services that run prover hardware on your behalf behind an API, typically bundled with an SDK, CI integration and autoscaling. Some are multi-zkVM, reducing lock-in at the operational layer.

**Strengths**

- Removes GPU capital expenditure and cluster operations entirely — the fastest path from a working guest program to proofs in production
- Lets you defer the buy-versus-build hardware decision until proof volume is known

**Tradeoffs**

- Introduces a liveness and censorship dependency on a single company: a proof you cannot generate is a system you cannot advance
- Cost per proof at steady volume is usually materially higher than self-hosting
- Sending witnesses to a third party can leak private inputs — for privacy applications this can defeat the entire purpose unless client-side witness generation is supported

**Choose it when:** Pre-product-market-fit teams, bursty or low-volume workloads, and proving over public inputs. A poor fit for privacy-critical witnesses or systems requiring censorship resistance.

Maintained by: Several vendors: Axiom (proving API), RISC Zero (remote proving and Boundless), Succinct (prover network), among others — none is endorsed here · Maturity: Commercially available; vendor maturity varies · License: Proprietary services over open-source zkVMs · Source: https://www.axiom.xyz/proving-api

Full page: https://zkpick.com/frameworks/hosted-proving/

#### Decentralised proof markets — *Operations — proof marketplaces*

> Decentralised proof markets: Operations — proof marketplaces. Protocols matching proof requests with a permissionless set of prover nodes using staking, bidding and on-chain settlement. Maturity: Live on mainnet; under a year of operating history. Maintained by: Boundless (RISC Zero) and the Succinct Prover Network are the leading examples; each is anchored to its sponsor's zkVM. Choose it when: Non-private, latency-tolerant, variable-volume demand where censorship resistance matters more than deterministic latency. Pair with a self-hosted fallback prover for critical paths.

Protocols matching proof requests with a permissionless set of prover nodes using staking, bidding and on-chain settlement. The leading examples are anchored to their sponsor's own zkVM.

**Strengths**

- Addresses the single-provider liveness and censorship risk that hosted services carry
- Competitive bidding can lower marginal cost, especially for bursty demand
- Permissionless prover entry creates a real supply side

**Tradeoffs**

- Both leading markets are anchored to their sponsor's zkVM and token — verify neutrality claims against what is supported today, not the roadmap
- Introduces token-economic and settlement risks orthogonal to your cryptography
- Latency and tail-latency guarantees are weaker than a dedicated prover
- Operating history is short relative to the value some systems would place on it

**Choose it when:** Non-private, latency-tolerant, variable-volume demand where censorship resistance matters more than deterministic latency. Pair with a self-hosted fallback prover for critical paths.

Maintained by: Boundless (RISC Zero) and the Succinct Prover Network are the leading examples; each is anchored to its sponsor's zkVM · Maturity: Live on mainnet; under a year of operating history · License: Protocol-specific · Source: https://docs.boundless.network/

Full page: https://zkpick.com/frameworks/proof-markets/

### How to run the selection

1. **Write down the statement and its volume** — What exactly is proved, how often, on what hardware, and where is it verified? Without these four numbers every framework comparison is aesthetic. Include the largest circuit you expect within two years, not the prototype.
2. **Eliminate on the hard constraints from §01** — Cross off anything that cannot target your chosen proof system, cannot meet the verifier cost budget, or carries a licence you cannot ship. This usually removes most of the field before any subjective comparison begins.
3. **Decide circuit versus zkVM explicitly, in writing** — Price both paths in engineer-months and in proving cost over a realistic horizon. Record the decision and its reasoning, because it is the assumption most likely to be revisited later under pressure.
4. **Prototype the hardest part, not the easiest** — Build the single most expensive component of your statement — the foreign-field operation, the hash loop, the recursion step — in the top two candidates. Fibonacci benchmarks tell you nothing about your workload.
5. **Measure the wrapping step separately** — Time and cost the recursion and on-chain wrapper independently of the base proof. It is frequently the bottleneck, and it is where a setup-free system can reacquire a trusted setup.
6. **Check the tooling you will depend on daily** — Run the debugger, write a negative test that mutates a witness and asserts the proof fails, and wire the available static analysis into CI. If any of these is missing, you will feel it every week for the life of the project.
7. **Diligence maintenance and disclosure before committing** — Check commit activity, release cadence and distinct recent contributors. Read the project's published security findings and how they were handled. Confirm the licence of every layer you ship with counsel.
8. **Record the decision and its expiry conditions** — Write down what would make you revisit: a backend change, a maintenance stall, a licence change, a proof cost that stops closing. A framework decision with no stated expiry conditions quietly becomes permanent.

### Where framework decisions go wrong

- **Choosing the framework before the backend** — A framework is chosen because someone on the team already knows it, and months later it cannot produce the proof size, verifier cost or setup story the product requires. By then the circuits exist and the cost of changing is measured in quarters.
  - *Mitigation:* Settle the proof system and its hard constraints first, then treat frameworks that cannot target it as non-candidates regardless of familiarity.
  - Full page: https://zkpick.com/frameworks/failure-modes/choosing-the-framework-before-the-backend/
- **Believing 'backend-agnostic' means you have options** — A project advertises multiple proving backends, but only one has CI, releases and issue traffic. The alternative backends are architectural possibilities that nobody currently maintains, and discovering this at migration time is expensive.
  - *Mitigation:* Treat a backend as real only if you can find recent commits, releases and issues for it — or if you validate it yourself and are prepared to maintain it.
  - Full page: https://zkpick.com/frameworks/failure-modes/believing-backend-agnostic-means-you-have-options/
- **Assuming a transparent system means no trusted setup anywhere** — A setup-free inner proof system is selected for exactly that property, then wrapped in a pairing-based SNARK to make on-chain verification affordable. The wrapper has its own setup, often inherited from a ceremony nobody on the team examined.
  - *Mitigation:* Trace the assumption to what the chain actually verifies. If a wrapper is used, its parameters are in scope: name their provenance and verify that transcript. See §04.
  - Full page: https://zkpick.com/frameworks/failure-modes/assuming-a-transparent-system-means-no-trusted-setup-anywhere/
- **Reading 'formally verified' as unconditional** — A project advertises formal verification and the claim is real but scoped — bounded by stated hypotheses, covering some components and not others. Bugs have been found by conformance testing in exactly the areas a verification effort did not cover.
  - *Mitigation:* Ask what was verified, against which specification, under what hypotheses, and what was explicitly out of scope. A precise, bounded claim is a good sign; an unqualified one is not.
  - Full page: https://zkpick.com/frameworks/failure-modes/reading-formally-verified-as-unconditional/
- **Benchmarking the demo instead of the workload** — Selection is driven by published throughput numbers on a trivial program. The real workload is dominated by foreign-field arithmetic or a hash loop with a completely different cost profile, and peak memory — not wall-clock time — turns out to decide feasibility.
  - *Mitigation:* Prototype your most expensive component in the top candidates and measure prover time, peak RAM and cost per proof on the hardware you will actually rent.
  - Full page: https://zkpick.com/frameworks/failure-modes/benchmarking-the-demo-instead-of-the-workload/
- **Discovering the licence after writing the code** — Copyleft compilers and standard libraries, AGPL provers and source-available licences restricting service offerings all appear among mainstream options, and the compiler, prover and verifier can each differ. The constraint surfaces when a commercial or hosted product is already built on it.
  - *Mitigation:* Enumerate the licence of every layer you ship before writing code, and get legal review rather than relying on forum consensus about what generated artefacts inherit.
  - Full page: https://zkpick.com/frameworks/failure-modes/discovering-the-licence-after-writing-the-code/
- **Adopting a fork whose maintenance has stopped** — A widely used fork is chosen because a lot of existing code depends on it, then turns out to be in declared maintenance mode — feature and architectural changes are no longer reviewed — so the team silently inherits responsibility for future security patches.
  - *Mitigation:* Check the maintenance posture of the specific fork, not the upstream project. If it is in maintenance mode, budget for owning it or choose differently for greenfield work.
  - Full page: https://zkpick.com/frameworks/failure-modes/adopting-a-fork-whose-maintenance-has-stopped/
- **Writing a custom precompile and forgetting what that means** — A zkVM is chosen partly to avoid hand-written circuits, and then a custom precompile is added for performance. That precompile is a hand-written circuit with all the attendant risk — but it is often reviewed as an optimisation rather than as new soundness-critical code.
  - *Mitigation:* Scope custom precompiles into the audit explicitly, as circuit code. Precompiles are a recurring source of soundness bugs precisely because they are written for speed.
  - Full page: https://zkpick.com/frameworks/failure-modes/writing-a-custom-precompile-and-forgetting-what-that-means/
- **Assuming an upstream audit covers your configuration** — A modular framework's audit is treated as covering the deployed system, but the audit examined the upstream base while your security depends on which extensions you enabled and how they interact.
  - *Mitigation:* Establish what the upstream audit actually covered and treat your specific instantiation — the enabled extensions and their composition — as a separate review target.
  - Full page: https://zkpick.com/frameworks/failure-modes/assuming-an-upstream-audit-covers-your-configuration/
- **Choosing a niche language and paying for it at audit time** — A framework with a small community is selected on technical merit. Hiring is slow, static analysis tooling does not exist for it, and audit quotes come back higher and longer because few reviewers can read it — costs that were never in the comparison.
  - *Mitigation:* Include auditor availability and tooling coverage as explicit selection criteria, and get an indicative audit quote for your top candidates before committing.
  - Full page: https://zkpick.com/frameworks/failure-modes/choosing-a-niche-language-and-paying-for-it-at-audit-time/

### Sources

1. [Circom — circuit compiler and language](https://github.com/iden3/circom) — project
2. [Noir — backend-agnostic circuit DSL](https://github.com/noir-lang/noir) — project
3. [Halo2 — upstream implementation (IPA, no trusted setup)](https://github.com/zcash/halo2) — project
4. [Halo2 — KZG fork](https://github.com/privacy-ethereum/halo2) — project
5. [halo2-lib — gadget library for Halo2 circuits](https://github.com/axiom-crypto/halo2-lib) — project
6. [gnark — Go zk-SNARK library](https://github.com/Consensys/gnark) — project
7. [arkworks — Rust cryptography library ecosystem](https://github.com/arkworks-rs) — project
8. [Plonky3 — polynomial IOP toolkit](https://github.com/Plonky3/Plonky3) — project
9. [Cairo — language and compiler](https://github.com/starkware-libs/cairo) — project
10. [Stwo — Circle STARK prover](https://github.com/starkware-libs/stwo) — project
11. [Leo — application language for Aleo](https://github.com/ProvableHQ/leo) — project
12. [o1js — TypeScript ZK DSL with native recursion](https://github.com/o1-labs/o1js) — project
13. [Barretenberg — the maintained Noir proving backend](https://github.com/AztecProtocol/aztec-packages/tree/master/barretenberg) — project
14. [Expander compiler collection — GKR prover and frontend](https://github.com/PolyhedraZK/ExpanderCompilerCollection) — project
15. [Sonobe — experimental folding-scheme library](https://github.com/ethereum/sonobe) — project
16. [powdr — zkVM compiler and eDSL toolkit](https://github.com/powdr-labs/powdr) — project
17. [Lurk — Lisp-like ZK language (dormant)](https://github.com/lurk-lab/lurk) — project
18. [SP1 — RISC-V zkVM](https://github.com/succinctlabs/sp1) — project
19. [SP1 on-chain verification — Solidity verifier and wrapper options](https://docs.succinct.xyz/docs/sp1/verification/solidity-sdk) — documentation
20. [sp1-contracts — deployed verifier gateways and addresses per chain](https://github.com/succinctlabs/sp1-contracts) — project
21. [SP1 security model — wrapper trusted setup provenance](https://docs.succinct.xyz/docs/sp1/security/security-model) — documentation
22. [On formal verification and a bug in SP1 Hypercube (EF zkEVM)](https://zkevm.ethereum.foundation/blog/sp1-fv) — analysis
23. [RISC Zero R0VM — zkVM](https://github.com/risc0/risc0) — project
24. [RISC Zero trusted setup ceremony rationale](https://dev.risczero.com/api/trusted-setup-ceremony) — documentation
25. [RISC Zero remote proving — hosted proving documentation](https://dev.risczero.com/api/generating-proofs/remote-proving) — documentation
26. [ZKsync Airbender — RISC-V prover for ZKsync OS, with benchmark harness](https://github.com/matter-labs/zksync-airbender) — project
27. [Zisk — Polygon's RISC-V zkVM](https://github.com/0xPolygonHermez/zisk) — project
28. [Pico — Brevis's modular RISC-V zkVM](https://github.com/brevis-network/pico) — project
29. [Ziren (formerly zkMIPS) — ZKM's MIPS zkVM](https://github.com/ProjectZKM/Ziren) — project
30. [ethproofs.org — continuous proving benchmarks across zkVMs on real Ethereum blocks](https://ethproofs.org/) — benchmark
31. [a16z zkvm-benchmarks — fixed-program comparison harness across zkVMs](https://github.com/a16z/zkvm-benchmarks) — benchmark
32. [OpenVM — modular zkVM framework](https://github.com/openvm-org/openvm) — project
33. [Missing subfield membership check in OpenVM pairing — CVE-2026-46669](https://blog.zksecurity.xyz/posts/openvm-bugs/) — disclosure
34. [Jolt — lookup-centric zkVM](https://github.com/a16z/jolt) — project
35. [Nexus zkVM — source-available RISC-V zkVM](https://github.com/nexus-xyz/nexus-zkvm) — project
36. [Valida — prover-optimised custom ISA zkVM](https://github.com/valida-xyz/valida) — project
37. [Miden VM — stack-based STARK VM](https://github.com/0xMiden/miden-vm) — project
38. [zkWASM — WebAssembly zkVM](https://github.com/DelphinusLab/zkWasm) — project
39. [Ceno — GKR-based zkVM (Scroll)](https://github.com/scroll-tech/ceno) — project
40. [Boundless — decentralised proof market documentation](https://docs.boundless.network/) — documentation
41. [Verified zk(E)VM project — formal verification of zkVMs](https://verified-zkevm.org/) — project
42. [RISC-V architectural certification tests](https://github.com/riscv-non-isa/riscv-arch-test) — test suite
43. [soundcalc — soundness parameter calculator for hash-based systems](https://github.com/ethereum/soundcalc) — tool
44. [Circomspect — static analyser for Circom](https://github.com/trailofbits/circomspect) — tool
45. [Picus — uniqueness verification for ZKP circuits](https://github.com/Veridise/Picus) — tool