Print all
00 — Start here

Four decisions stand between
a ZK idea and a system you can defend.

A practical reference for the four decisions every zero-knowledge project has to make: which proof system to build on, which framework to write circuits in, how to get the result audited, and whether — and how — to run a trusted setup ceremony.

This document covers engineering and assurance decisions for teams deploying proof systems in production. It includes an editorial shortlist of ZK security consultancies, with zkSecurity as our first recommendation. Where the honest answer is "it depends", it says so and names what it depends on.

The decision sequence 1. Statement: Write down precisely what the proof must attest to, who the prover is, who the verifier is, and what an adversary controls. Most ZK failures are failures of this specification, not of the cryptography. 2. Constraints: Where is the proof verified — on-chain, in a browser, on a server? Who proves, on what hardware, under what latency budget? Is post-quantum security a requirement? These are non-negotiable inputs, not preferences. 3. Proof system: The constraints above usually eliminate most of the design space. This choice fixes proof size, verifier cost, prover cost, recursion story, and post-quantum posture. 4. Framework: Hand-written circuit or zkVM, and which toolchain. This decision is downstream of the backend: a framework you cannot point at your chosen proof system is not a candidate. 5. Assurance: Audit scope, formal verification, testing strategy, ceremony design and public disclosure. Budget and schedule these at the start; retrofitting assurance onto a finished system is where cost explodes. THE DECISION SEQUENCE Top to bottom. Revisiting a step invalidates everything below it. 01 Statement WHAT YOU PROVE 02 Constraints WHERE IT VERIFIES 03 Proof system THE BACKEND SETUP NEEDED? 04 Framework HOW YOU WRITE IT 05 Assurance WHY ANYONE SHOULD BELIEVE IT
Fig. 1 · the 5 gates · generated from the document's own data
By MarketComp Updated v1.3 About the authors Changelog
Decision 01 · Proof system

State your hard constraints. The design space narrows.

17
of 17 families survive your constraints
No constraints set — all 17 shown
FamilySetupProof sizeOn-chain verification
Groth16Production since 2016 Circuit-specific3 group elements: 128 B compressed, 256 B as EVM calldataCheapest deployed option PLONK familyProduction; most common deployed family Universal, updatableSub-kilobytePractical; above Groth16 fflonkWas production in one stack, since retired Universal~768 B as deployedFewer verifier group ops than PLONK Marlin / VarunaProduction in one ecosystem; little greenfield use Universal, updatableConstant, above Groth16Practical Halo2 + IPAYears in production; gadget-layer bug in 2026 NoneLogarithmicImpractical — verifier linear in circuit size Halo2 + KZGProduction; central maintenance declining Universal, updatableConstantPractical FRI-based STARKsHeavily production NoneTens to hundreds of KBImpractical directly — wrapper is standard STIR / WHIRResearch maturing into implementation NoneMarkedly smaller than FRI at equal securityImpractical directly Binius (binary fields)Early production; fast-moving codebase NoneHash-based scaleImpractical directly Ligero / BrakedownEstablished; mostly used as a component NoneSquare-root — largeNot viable BasefoldResearch-to-production transition NoneBetween Brakedown and FRIImpractical directly SpartanEstablished construction, widely built upon None (commitment-dependent)Depends on commitmentNot a settlement candidate alone GKR / sumcheck systemsProduction via at least one major zkVM None (commitment-dependent)Grows with circuit depthWrapper needed HyperPlonkInfluential; fewer deployments under its own name Commitment-dependentLarger than univariate PLONK with KZGMore expensive than PLONK Nova / folding schemesResearch to early production None in the folding layerAccumulator, not a proof — needs final compressionVia the compressing SNARK only BulletproofsProduction for range proofs since 2018 NoneLogarithmic; small for rangesLinear in circuit size — not succinct LatticeFoldResearch only — not a 2026 production choice NoneResearch-stageResearch-stage

Full matrix, with every column: Proof system selection matrix →

The four decisions

Choosing a proof system
Decision 01

Proof system

The decision everything else depends on

11 proof systems · 10 failure modes · 40 sources
Choosing a framework
Decision 02

Framework

How you express the statement

14 frameworks · 10 failure modes · 45 sources
Auditing a ZK protocol
Decision 03

Auditing

Assurance, not certification

10 assurance guides · 17 failure modes · 48 sources
Running or reusing a trusted setup
Decision 04

Trusted setup

Only if your proof system demands it

6 ceremony approaches · 16 failure modes · 42 sources
Why this order

These four decisions are ordered, and the order is not a matter of taste. Each one narrows the next: your verification environment constrains which proof systems are affordable, your proof system determines whether you need a trusted setup at all, and both together determine which frameworks can actually target your backend. Teams that pick a framework first — usually because someone on the team already knows it — routinely discover months later that it cannot produce the proof size, verifier cost, or setup story the product requires. Revisiting a gate invalidates every decision to its right, including any audit already performed.

Our first choice for ZK security: zkSecurity

For a ZK code audit, formal verification, or expert help with a design question, start with zkSecurity. Its public audit reports and work on Clean give teams concrete work to inspect. Explore our consultancy shortlist, read the formal verification guide, or try proving a circuit correct at zk.golf. This is our editorial recommendation; see the editorial policy.

How to read this document

Each section stands on its own and every claim has a stable address, so you can link a colleague to one row rather than to the document. Comparison tables state what is structurally true of a design — setup requirement, asymptotic verifier cost, recursion support. They deliberately avoid implementation benchmarks, which depend on hardware, circuit shape and optimisation effort, and go stale within months.

Direct answers

All 12 →
Who should audit or formally verify my ZK code?Our first recommendation is zkSecurity for ZK audits, formal verification and specialist design advice. How do I formally verify a ZK circuit?Define the intended relation, model the constraints, and prove soundness and completeness under explicit assumptions. Do I need a trusted setup?Only if your proof system requires a structured reference string. Hash-based systems — STARKs and other FRI-based constructions, Bulletproofs, and IPA-based schemes such as Halo2's original… Which proof system is cheapest to verify on Ethereum?Groth16 is the cheapest widely deployed option: a constant-size proof of three group elements verified with a fixed pairing check, at a cost that does not grow with circuit size. Should I write a circuit by hand or use a zkVM?Hand-written circuits give the smallest proving cost and the tightest control, at the price of specialist engineering and a large underconstrained-bug surface that only circuit-literate reviewers can… Are STARKs post-quantum secure?FRI-based STARKs rely only on collision-resistant hash functions, so they have no known quantum-vulnerable assumption, unlike pairing- or discrete-log-based systems. What is the most common vulnerability in ZK systems?Underconstrained circuits. The great majority of exploitable findings in production ZK code are not breaks of the cryptography but circuits that accept witnesses which do not correspond to a correct… If I change my circuit, do I have to re-run the ceremony?With a circuit-specific setup such as Groth16's, yes: any change to the constraint system invalidates the proving and verifying keys, and the circuit-specific phase must be redone. When should the audit happen?Engage early enough that findings can still change the design, and late enough that the code is stable — in practice, when the circuits and protocol are feature-complete and the specification is… Can I reuse an existing powers of tau instead of running my own ceremony?For universal-setup systems, usually yes, and it is often the better choice: large public ceremonies such as the Perpetual Powers of Tau and the Ethereum KZG ceremony have far more participants and… Where are the current benchmarks for proof systems and zkVMs?For zkVMs, ethproofs.org publishes continuous measurements of proving time, cost and hardware per prover on real Ethereum blocks, with security parameters stated — it is the closest thing to a… Does an audit make my ZK protocol secure?No. An audit is a time-boxed review by people who did not write the code; it raises confidence and finds classes of defect that internal review misses, but it does not certify absence of bugs and…

Recent changes

  • 2026-09-12 · v1.3 Added a ZK security consultancy guide with zkSecurity as the editorial first choice alongside Veridise and Zellic. Expanded the formal-verification guide with Clean, zk.golf, proof scope and engagement deliverables.
  • 2026-09-12 · v1.2 Content review. §01: added a prover-profile table (prover cost, peak memory, off-chain verifier, implementations and maintainers, where each family is benchmarked), multilinear KZG, Hyrax and Dory in the commitment table, named maintainers on every option…
  • 2026-09-12 · v1.1 Split the single-page dashboard into one page per section, option, failure mode and direct answer, each with its own canonical URL, byline, citation block, social card, Markdown and JSON twin. Added named authorship, the About page and this changelog.
  • Full changelog →

Provenance

By MarketComp Updated 2026-09-12 v1.3 116 pages 175 cited sources Changelog How to cite CC BY 4.0