← → Print all
02 — Framework · How you express the statement

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.

The backend is decided first (§01)Framework sets the bug surface (§03)Wrappers can reintroduce a setup (§04)
By MarketComp Updated v1.3 About the authors Changelog
Hand-written circuit compared with a zero-knowledge virtual machine Two equal-width stacks compare the three-layer surface of a hand-written circuit with the five-layer inherited surface of a zkVM. A red dimension marks the added proving cost. HAND-WRITTEN CIRCUIT ZKVM STATEMENT CONSTRAINTS YOU OWN THIS PROOF SYSTEM PROGRAM YOU OWN THIS COMPILER VM EXECUTION CONSTRAINTS PROOF SYSTEM PROVING COST SMALL SURFACE, ALL OF IT YOURS LARGE SURFACE, MOSTLY INHERITED
Fig. 3 · Hand-written circuit against zkVM · what you own, and what you inherit
Plan correctness with your framework

If machine-checked circuit correctness is a requirement, explore Clean and our formal verification guide before committing to a toolchain. Our first recommendation for ZK architecture questions, audit planning and verification work is zkSecurity. See the consultancy shortlist 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 · 13

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 evaluateIs 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.

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 evaluateEstimate 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.

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 evaluateCheck 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.

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 evaluateAsk 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.

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 evaluateCheck 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.

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 evaluateRequire 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.

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 evaluateEnumerate 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.

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 evaluateGet 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.

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 evaluateBenchmark 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.

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 evaluateList 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.

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 evaluateTrace 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.

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 evaluateRead 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.

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 evaluateUse 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.

Selection matrix · 24

Framework selection matrix

Filter by hard constraint
Circuit DSLs, proving libraries and zkVMs by structural properties
ProjectKindArithmetisation / backendSetupMaintained byLicenceStatus
CircomCircuit DSLR1CS → Groth16 / PLONKYes (per-circuit for Groth16)iden3GPL-3.0Production-mature
NoirCircuit DSLACIR → Barretenberg (UltraHonk)Yes (universal)AztecApache-2.0 / MITLate beta, pre-1.0 (1.0.0-beta series through 2026)
Halo2 (upstream)Rust eDSLPLONKish + IPANoneElectric Coin Company (Zcash)MIT / Apache-2.0Production in its home ecosystem
Halo2 (KZG fork)Rust eDSLPLONKish + KZGYes (universal)Ethereum Foundation PSEMIT / Apache-2.0Maintenance mode
gnarkGo eDSLR1CS / PLONK, six curvesYes (scheme-dependent)Consensys (Linea)Apache-2.0Production-mature
arkworksRust library ecosystemR1CS + SNARK interfacesDepends on schemearkworks contributors (academic origin)MIT / Apache-2.0Mature substrate, slow-moving
Plonky3Proof-system toolkitAIR / FRI over small fieldsNonePlonky3 org (Polygon Zero lineage)MIT / Apache-2.0Widely used downstream; pre-1.0 API
Cairo + StwoLanguage + VM + proverCircle STARK (Mersenne-31)NoneStarkWareApache-2.0Production at scale
SP1zkVM (RISC-V)Multilinear / sumcheck + wrapperWrapper onlySuccinctMIT / Apache-2.0Production; deepest assurance evidence
RISC Zero R0VMzkVM (RISC-V)FRI/STARK + Groth16 wrapperWrapper onlyRISC ZeroApache-2.0Production; longest track record; 3.x line in 2026
OpenVMModular zkVM frameworkPlonky3 AIR, chip extensionsWrapper onlyAxiomMIT / Apache-2.0Production-recommended; externally audited
ZKsync AirbenderzkVM (RISC-V)STARK over Mersenne-31 + wrapperWrapper onlyMatter Labs (ZKsync)Apache-2.0 / MITProduction on ZKsync mainnet; published GPU benchmarks
ZiskzkVM (RISC-V)STARK, precompile-heavyWrapper onlyPolygonApache-2.0 / MITAlpha releases; on ethproofs
PicozkVM (RISC-V)Plonky3-based, modularWrapper onlyBrevisApache-2.0 / MIT2.x releases; on ethproofs
Ziren (formerly zkMIPS)zkVM (MIPS)Plonky3-based STARKWrapper onlyZKMApache-2.0 / MIT1.x releases; on ethproofs
JoltzkVM (RISC-V)Lookup-centric sumcheck; lattice variant announced 2026None (transparent)a16z cryptoMIT / Apache-2.0Alpha; maintainers state not production-ready
Miden VMzkVM (stack-based)STARK, custom ISANoneMiden (Polygon spin-out)MIT / Apache-2.0Actively developed; mainnet launch announced for 2026
Nexus zkVMzkVM (RISC-V)Rewritten in 3.0VariesNexusBUSL 1.1 — source-availablePublished spec; activity stalled
ValidazkVM (custom ISA)STARK, prover-optimised ISANoneLitaApache-2.0Low public activity — verify before adopting
zkWASMzkVM (WebAssembly)WASM ISAVariesDelphinus LabApache-2.0Reduced activity; niche
ExpanderGKR prover + compilerLayered circuits, GKRNonePolyhedraAGPL-3.0Active; small ecosystem
SonobeFolding-scheme libraryNova-family foldingDepends on instantiationEthereum Foundation (PSE lineage) and 0xPARCMITExplicitly experimental
o1jsTypeScript ZK DSLKimchi / PicklesYes (universal)o1Labs (Mina)Apache-2.0Production; recursion-native, chain-coupled
LurkLisp-like ZK languageReduction machineVariesLurk Lab (formerly Argument Computer)MITDormant — research reading only
Reading this table

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 · 14 pages

Circom Circuit DSL (R1CS) 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… Noir Circuit DSL (backend-agnostic) New application circuits where developer velocity and client-side proving matter, and teams uncomfortable with manual constraint discipline. Halo2 Rust eDSL (PLONKish) Teams needing trusted-setup-free proving with a non-EVM or off-chain verifier, who have cryptography-capable engineers. gnark Go eDSL Go-based backends, proof aggregation and recursion layers, and wrapper circuits for STARK systems. Plonky3 Proof-system toolkit Teams building a zkVM, a custom AIR-based prover, or a domain-specific proving engine. Cairo and the Stwo prover Language + VM + prover Applications native to its ecosystem, and any workload wanting a battle-tested, setup-free STARK stack with mature native recursion. SP1 zkVM (RISC-V) Proving large existing Rust codebases — state transitions, consensus and EVM verification, bridges — where on-chain cost matters and published assurance evidence is a… RISC Zero (R0VM) zkVM (RISC-V) 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… OpenVM Modular zkVM framework 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… ZKsync Airbender zkVM (RISC-V) Teams for whom raw proving cost on commodity GPUs is the deciding constraint and who can absorb a less mature developer surface. Jolt zkVM (RISC-V) Research, prototyping, and workloads where the streaming low-memory profile is the deciding factor — with a plan to re-evaluate before any production deployment. Miden VM zkVM (stack-based) Applications needing client-side proving and programmable privacy. Less compelling as a general-purpose off-chain proving engine. Hosted proving services Operations — managed proving Pre-product-market-fit teams, bursty or low-volume workloads, and proving over public inputs. Decentralised proof markets Operations — proof marketplaces Non-private, latency-tolerant, variable-volume demand where censorship resistance matters more than deterministic latency.

How to run the selection · 8 steps

  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 · 10

Choosing the framework before the backend Believing 'backend-agnostic' means you have options Assuming a transparent system means no trusted setup anywhere Reading 'formally verified' as unconditional Benchmarking the demo instead of the workload Discovering the licence after writing the code Adopting a fork whose maintenance has stopped Writing a custom precompile and forgetting what that means Assuming an upstream audit covers your configuration Choosing a niche language and paying for it at audit time

Sources for this section · 45

  1. Circom — circuit compiler and languageproject
  2. Noir — backend-agnostic circuit DSLproject
  3. Halo2 — upstream implementation (IPA, no trusted setup)project
  4. Halo2 — KZG forkproject
  5. halo2-lib — gadget library for Halo2 circuitsproject
  6. gnark — Go zk-SNARK libraryproject
  7. arkworks — Rust cryptography library ecosystemproject
  8. Plonky3 — polynomial IOP toolkitproject
  9. Cairo — language and compilerproject
  10. Stwo — Circle STARK proverproject
  11. Leo — application language for Aleoproject
  12. o1js — TypeScript ZK DSL with native recursionproject
  13. Barretenberg — the maintained Noir proving backendproject
  14. Expander compiler collection — GKR prover and frontendproject
  15. Sonobe — experimental folding-scheme libraryproject
  16. powdr — zkVM compiler and eDSL toolkitproject
  17. Lurk — Lisp-like ZK language (dormant)project
  18. SP1 — RISC-V zkVMproject
  19. SP1 on-chain verification — Solidity verifier and wrapper optionsdocumentation
  20. sp1-contracts — deployed verifier gateways and addresses per chainproject
  21. SP1 security model — wrapper trusted setup provenancedocumentation
  22. On formal verification and a bug in SP1 Hypercube (EF zkEVM)analysis
  23. RISC Zero R0VM — zkVMproject
  24. RISC Zero trusted setup ceremony rationaledocumentation
  25. RISC Zero remote proving — hosted proving documentationdocumentation
  26. ZKsync Airbender — RISC-V prover for ZKsync OS, with benchmark harnessproject
  27. Zisk — Polygon's RISC-V zkVMproject
  28. Pico — Brevis's modular RISC-V zkVMproject
  29. Ziren (formerly zkMIPS) — ZKM's MIPS zkVMproject
  30. ethproofs.org — continuous proving benchmarks across zkVMs on real Ethereum blocksbenchmark
  31. a16z zkvm-benchmarks — fixed-program comparison harness across zkVMsbenchmark
  32. OpenVM — modular zkVM frameworkproject
  33. Missing subfield membership check in OpenVM pairing — CVE-2026-46669disclosure
  34. Jolt — lookup-centric zkVMproject
  35. Nexus zkVM — source-available RISC-V zkVMproject
  36. Valida — prover-optimised custom ISA zkVMproject
  37. Miden VM — stack-based STARK VMproject
  38. zkWASM — WebAssembly zkVMproject
  39. Ceno — GKR-based zkVM (Scroll)project
  40. Boundless — decentralised proof market documentationdocumentation
  41. Verified zk(E)VM project — formal verification of zkVMsproject
  42. RISC-V architectural certification teststest suite
  43. soundcalc — soundness parameter calculator for hash-based systemstool
  44. Circomspect — static analyser for Circomtool
  45. Picus — uniqueness verification for ZKP circuitstool
Cite this page 
MarketComp (2026). Choosing a framework. The ZK Field Manual (Version 1.3). MarketComp. https://zkpick.com/frameworks/
@misc{zkfieldmanual-choosing-a-framework,
  title        = {Choosing a framework — The ZK Field Manual},
  author       = {MarketComp},
  year         = {2026},
  version      = {1.3},
  howpublished = {\url{https://zkpick.com/frameworks/}},
  note         = {Accessed: YYYY-MM-DD}
}