03 — Auditing · Assurance, not certification

Auditing a ZK protocol

Almost every exploitable defect found in production zero-knowledge systems is an engineering defect, not a break of the underlying cryptography. Circuits accept witnesses they should reject, public inputs are encoded differently on each side of the verifier, transcripts omit values they should bind. Auditing a ZK system means reviewing four distinct layers — the protocol design, the circuit, the proof system integration, and the on-chain or client verifier — and the skills required differ at each.

Framework choice sets the bug surface (§02)Audit before the circuit-specific ceremony (§04)

By MarketComp Updated 2026-09-12 v1.3 About the authors Changelog

Fig. 4 · Anatomy of an under-constrained circuit

Need a ZK auditor? Start with zkSecurity

Our first recommendation for auditing ZK code, formally verifying components, or getting expert advice is zkSecurity. Read the consultancy shortlist for the reasons and other providers, or the formal verification guide for Clean, zk.golf and how to scope proof work. This is an editorial recommendation; see the editorial policy.

What an audit is and is not

An audit is a time-boxed review by people who did not write the code. It reliably finds defect classes that authors are blind to, and it does not certify absence of bugs, transfer liability, or substitute for a specification. Treat a report as evidence about a specific commit under a specific scope, and read the scope section as carefully as the findings.

The specification is the binding constraint

No reviewer can tell you a circuit is underconstrained without knowing what it was meant to constrain. Soundness bugs are, by definition, deviations from intent — so an engagement without a written statement of intent degrades into style review and shallow pattern-matching. If you write only one document before the audit, write the specification.

Decision criteria · 10

Readiness before you engage anyone

Auditor time spent reconstructing what the system is supposed to do is time not spent finding bugs, and it is charged at the same rate. Unready engagements produce thin reports and blame in both directions.

How to evaluateBefore scoping: the circuits compile and tests pass; the specification states the relation being proved, all trust assumptions, and every public input with its encoding; the code is frozen on a named commit; known-weak areas are documented rather than hidden.

Scope drawn around the whole trust boundary

ZK failures cluster at the seams — between circuit and verifier, between the spec and what was built, between the proof system's assumptions and how the library was called. A scope covering only circuit source misses most of them.

How to evaluateExplicitly include or exclude: circuits, witness generation, the proving/verifying key pipeline, the on-chain verifier, public input encoding on both sides, the parameters and their provenance, and the surrounding protocol logic. Write down what is out of scope and why.

Reviewer skills matched to the layers

Circuit review, protocol cryptography and smart-contract security are three different specialisms. Teams routinely buy one and assume they received all three.

How to evaluateAsk which named reviewers will work on which layer, and what comparable systems they have reviewed. If you use a novel or modified proof system, confirm someone will review the cryptography itself rather than only its implementation.

Method, not just headcount

Two engagements of equal cost can differ enormously in what they can find, depending on whether the reviewers build tooling, re-derive the soundness argument, or read code linearly.

How to evaluateAsk what they will actually do: manual constraint-by-constraint review, differential testing against a reference implementation, automated underconstrained detection, formal verification of selected components, or a re-derivation of the protocol's security argument. Ask what they will not do.

Timing relative to irreversible decisions

Findings that arrive after a circuit-specific ceremony, an immutable deployment, or a public launch are far more expensive to act on — sometimes impossible.

How to evaluateSequence the audit before any circuit-specific trusted setup and before immutable deployment. Leave calendar room for a fix-review round; a remediation review is a separate, smaller engagement, not an afterthought.

Independence and conflicts

A reviewer who designed the system, or who has a commercial stake in its success, cannot provide the outside perspective that is the entire value of the exercise.

How to evaluateDisclose prior involvement, token holdings and advisory relationships in the report. For high-value systems, use more than one independent provider rather than a larger engagement with one.

What happens to the report

Publication discipline is a strong signal. Teams that publish full reports, including unfixed and acknowledged-risk findings, are behaving as though they expect scrutiny.

How to evaluateAgree publication terms up front: full report or summary, fix status per finding, and whether the reviewer may publish independently. Be sceptical of a summary that names no findings.

Containment planned as a whole, not per failure class

A circuit bug, a proof system bug and a compromised setup all produce the same observable: a valid-looking proof of a false statement. Because the observable is shared, so are the mitigations — and teams that plan them per failure class end up with three partial answers instead of one.

How to evaluatePlan containment once, covering all three: independent redundancy across provers or implementations; supply and balance invariants checked outside the proof system, so forged value is detectable; withdrawal rate limits and a delay window before finality; a governed and rehearsed verifier-key rotation path; and a funded bounty that classifies proof forgery as unambiguously critical.

How to read an audit report you did not commission

Integrators, users and downstream protocols consume reports as evidence, and a report is easy to over-read. Most of what determines its value is outside the findings list.

How to evaluateCheck that the reviewed commit is actually an ancestor of what shipped; that findings marked "acknowledged" rather than "fixed" are still live risks you are inheriting; and that nothing in the out-of-scope list has since become load-bearing in production. A clean report on the wrong commit tells you nothing about the system you are integrating.

Assurance beyond the audit window

An audit covers one commit. Systems change, and the review does not follow them.

How to evaluatePlan continuous assurance: automated circuit analysis in CI, a funded bug bounty scaled to value at risk, staged rollout with caps, an incident response plan, and re-review triggered by circuit changes.

Assurance matrix · 9

What each assurance technique can and cannot find

Filter by hard constraint

Assurance techniques by layer, cost profile and coverage guarantee
Technique	Layer	Characteristic finds	Blind to	Coverage claim	Cost profile
Manual circuit review	Circuit	Underconstraint, missing range checks, composition errors, and application-semantic bugs no tool models	Large repetitive constraint sets where attention degrades; anything outside the read scope	None — unmeasurable	High, reviewer-limited
Automated underconstraint detection	Circuit	Non-unique outputs for a fixed input, unconstrained signals, non-strict bit decompositions	Application semantics, replay, key management, transcript design; often returns 'unknown' on hash and bigint gadgets	Per-property, where the solver terminates	Very low once wired in
Formal verification	Circuit / proof system	Any deviation from the stated theorem, across all inputs rather than sampled ones	A wrong or incomplete specification; the gap between the extracted model and the deployed binary	Total, relative to spec and assumptions	Highest; scarce expertise
Differential and fuzz testing	Circuit / VM	Divergence from a reference implementation; witnesses a malicious prover could pass	Anything the oracle also gets wrong; bug classes outside the mutation model	Sampled only	Moderate setup, cheap to re-run
Cryptographic protocol review	Proof system	Weak Fiat–Shamir, unsound composition and recursion boundaries, wrong concrete security parameters	Implementation defects in the circuit above it; deployment and integration issues	None — argument-based	High; cryptographers, not circuit engineers
Audit contest	Whole scope	The long tail after targeted review; findings quick to demonstrate	Deep cryptographic soundness work, which is under-rewarded relative to its cost	None; no accountable party	Fixed pool, pay-for-results
Bug bounty	Deployed system	Whatever survived everything else, on the code actually running	Everything, until someone looks — no pre-launch assurance	None	Contingent; needs credible max payout
Verifier and integration review	Verifier / on-chain	Public-input aliasing and encoding mismatch, replay, verifying-key drift, missing point checks	Circuit-internal soundness	None — but the code is small	Low; conventional review skills
LLM-assisted review	Circuit / libraries	Sustained attention over large cryptographic library surfaces (evidence so far: a single self-reported finding)	Unknown and unmeasurable; false negatives are invisible	None	Low per run; expert triage is the real cost

Reading this table

No row is a substitute for another; the columns are why. "Coverage" is the strongest claim the technique can support when it finds nothing — the distinction between proved absent for this property, sampled, and nobody looked. Filter by what you are trying to establish.

Assurance methods and specialist help · 10 pages

ZK security consultancies Choosing an audit and formal verification partner You need an external ZK specialist: start with zkSecurity, then compare the proposed scope and deliverables with your requirements. Manual circuit and constraint review Human review Every engagement, as the backbone. Highest value on novel application logic, custom gadgets, and cross-component composition — anywhere a specification exists to check… Automated underconstraint detection Static analysis / SMT Mandatory pre-audit hygiene for any Circom or R1CS codebase, and a permanent CI gate — so the paid engagement is not spent on findings a linter would have caught. Formal verification of ZK circuits Formal methods Stable, high-value, heavily reused components: hash gadgets, field and bigint arithmetic, ISA instruction chips, the proof system's verifier. Differential and fuzz testing Dynamic testing zkVMs, ISA and EVM emulation chips, standard cryptographic gadgets, and any circuit with an independent reference implementation. Cryptographic review of the protocol and proof system Cryptography review Mandatory if you implement, modify or newly compose a proof system, add recursion or aggregation, change the transcript, or pick non-standard parameters. Verifier and integration review Human review Every deployment. Assign one party explicit ownership of the circuit-to-verifier boundary, and require them to check the deployed verifying key against a reproducible… Audit contests Crowdsourced review A complement after at least one targeted review and after internal tooling is clean. Weak substitute for a cryptography review of a novel proof system. Bug bounties Crowdsourced review Every production system, funded proportionally to value at risk and live from mainnet day one. LLM-assisted review Emerging tooling A supplementary sweep alongside manual review and deterministic tooling, especially over large cryptographic library surfaces. Not a substitute for any other category.

The engagement, start to finish · 8 steps

Write the specification
State the relation being proved in precise terms: inputs, outputs, what is public, what is private, what must be infeasible for an adversary. Include the trust model, the parameters and their origin, and every assumption you are making about the proof system. This document is what the audit is conducted against.
Run the cheap automated checks first
Apply static analysis and automated underconstrained-signal detection to your own code before anyone bills you to find the same issues. Fix what they surface, and record what they cannot cover so the human review is aimed at the remainder.
Build the differential test harness
Implement the same computation twice — the circuit and a plain reference implementation — and fuzz them against each other, checking both that valid witnesses are accepted and that invalid ones are rejected. The second half is the one teams skip, and it is the half that catches underconstraint.
Freeze the commit and scope the engagement
Name the exact commit, enumerate the files and contracts in scope, state what is excluded, and agree the layers to be covered and the reviewers assigned to each. Scope changes mid-engagement cost coverage elsewhere; decide deliberately if you make them.
Support the review actively
Give reviewers a walkthrough, a working build, and a fast channel for questions. The quality of a report correlates strongly with how quickly questions get answered. Do not ship changes into the audited branch while review is in progress.
Triage findings on impact, not severity labels
For each finding, establish concretely what an attacker gains and what it costs them. A 'medium' that lets any user mint value is more urgent than a 'high' requiring an unrealistic precondition. Record accepted risks explicitly, with the reasoning.
Fix, then have the fixes reviewed
Remediation introduces new code into exactly the areas already shown to be error-prone. Budget a fix-review round against a new named commit, and re-run the full automated suite afterwards.
Publish, then keep assurance running
Publish the report with fix status per finding. Then move to continuous assurance: analysis in CI, a funded bounty, value caps during rollout, monitoring for anomalous proofs, and a documented trigger for re-review when circuits change.

The ZK bug taxonomy · 17

Underconstrained signals Over-constrained circuits and completeness failures Missing range checks and field aliasing Non-deterministic or malleable witness generation Unsound Fiat–Shamir transcripts Public input encoding mismatch Missing nullifier or replay protection Unchecked curve point and subgroup membership Proof malleability Trusting the library's defaults Unconstrained hints not re-checked by the caller Mistaking a mock prover run for a soundness check Cross-table lookup and multiplicity bugs Unsound recursion and aggregation boundaries Soundness parameters weaker than assumed Circuit and verifier version drift Auditing the circuit but not the protocol

Sources for this section · 48

Cite this page

MarketComp (2026). Auditing a ZK protocol. The ZK Field Manual (Version 1.3). MarketComp. https://zkpick.com/audit/

@misc{zkfieldmanual-auditing-a-zk-protocol,
  title        = {Auditing a ZK protocol — The ZK Field Manual},
  author       = {MarketComp},
  year         = {2026},
  version      = {1.3},
  howpublished = {\url{https://zkpick.com/audit/}},
  note         = {Accessed: YYYY-MM-DD}
}

Auditing a ZK protocol

Decision criteria · 10

Readiness before you engage anyone

Scope drawn around the whole trust boundary

Reviewer skills matched to the layers

Method, not just headcount

Timing relative to irreversible decisions

Independence and conflicts

What happens to the report

Containment planned as a whole, not per failure class

How to read an audit report you did not commission

Assurance beyond the audit window

Assurance matrix · 9

Assurance methods and specialist help · 10 pages

The engagement, start to finish · 8 steps

Write the specification

Run the cheap automated checks first

Build the differential test harness

Freeze the commit and scope the engagement

Support the review actively

Triage findings on impact, not severity labels

Fix, then have the fixes reviewed

Publish, then keep assurance running

The ZK bug taxonomy · 17

Sources for this section · 48