You are watching a ZK rollup process a token transfer. The prover submits its proof, the verifier runs its check, the chain records the result, and somewhere in that sequence ten tokens materialize from nothing. No alert fires. No transaction reverts. The block explorer shows a clean confirmation, green all the way down.
Nobody's alarm goes off.
That is the core problem with a silent inflation bug in a zero-knowledge proof system: the cryptography does not lie, but it also does not care about the question you forgot to ask. Understanding why these bugs evade detection requires getting specific about where the proof ends and the protocol begins.
The Gap Between "Valid Proof" and "Correct Outcome"
A ZK proof system is, at its mathematical heart, a machine that answers exactly one question: does the prover know a witness that satisfies this particular arithmetic circuit? The circuit is the specification. If the circuit is wrong, a valid proof proves the wrong thing, perfectly.
This is where most confusion starts. People treat "proof verified" as synonymous with "system behaved correctly." Those are two very different claims.
Consider a simplified balance circuit for a token transfer. It needs to enforce three things: the sender's new balance equals the old balance minus the transfer amount, the recipient's new balance equals the old balance plus the transfer amount, and no balance goes below zero. Miss that third constraint and a prover can manufacture a valid proof for a transfer where the sender's balance wraps around a 254-bit field to become an astronomically large positive number. The proof verifies. The math checks out. The constraint that was specified is satisfied, and the constraint that was not specified does not exist as far as the circuit is concerned.
That is an underconstraint bug. The circuit has a hole, and that hole is invisible to the verifier because the verifier only checks what it has been told to check.
Three Specific Failure Modes, and Why Each Hides
Underconstraint: the silent permission slip. The scenario above is the canonical case. A real-world version surfaced during a Zcash cryptographic library audit before mainnet launch: a bug in the Bellman library left certain constraints on elliptic curve point validity unenforced, which could, under specific conditions, allow malformed proofs to pass. The fix was a circuit-level patch. The proof system itself was never broken. The specification of what to prove was simply incomplete.
Underconstrained bugs hide because the prover can always find a valid witness. There is no cryptographic failure, no rejected transaction, no error log. The system hums along producing green checkmarks.
Field arithmetic overflow: the number that wraps around. ZK circuits operate over finite fields, typically a prime field where arithmetic wraps modulo a large prime p. An integer that looks like -1 in ordinary arithmetic is actually p-1 in this field, a very large positive number. If a circuit checks `new_balance >= 0` using native field arithmetic without a proper range proof, an attacker can submit a balance of p-1, which satisfies the non-negativity check because p-1 is positive in the field, even though it represents a catastrophic underflow in the protocol's intended semantics.
Range proofs exist precisely to prevent this. But they cost constraints, which cost proving time, which creates pressure to skip or simplify them. That pressure is exactly where bugs are born.
Trusted setup vulnerabilities: the toxic waste problem. Some proof systems, Groth16 being the most widely deployed, require a one-time setup ceremony that produces public parameters. If the randomness used in that ceremony is retained by any participant, those parameters are compromised: that person can forge proofs for any statement in the system. Forged proofs are indistinguishable from honest ones. The inflation is unlimited, the detection surface is zero, and nothing shows up unless you audit the ceremony itself.
The Zcash Powers of Tau ceremony and subsequent upgrades involved hundreds of participants precisely because the security model requires that at least one participant honestly discarded their randomness. Verifying ceremony integrity is an operational and social problem, not a cryptographic one. It does not appear in any smart contract audit.
Why Standard Auditing Misses These
Traditional smart contract audits look at Solidity or Rust code and reason about state transitions. A ZK circuit audit requires reasoning about arithmetic constraint systems, usually written in domain-specific languages like Circom, Halo2's constraint API, or Cairo. The tooling is younger, the auditor pool is smaller, and the failure modes are genuinely unintuitive.
A Circom circuit compiles to an R1CS (Rank-1 Constraint System), a set of equations of the form `(a · b = c)`. An auditor needs to verify that the set of satisfying assignments to these equations corresponds exactly to the intended set of valid program executions. That is not a code review. It is a mathematical equivalence proof, closer in character to the kind of argument you would find in an appellate brief than in a security checklist. Automated tools like ZKAP and Picus can flag some underconstraint classes, but they are not exhaustive, and many projects do not run them.
There is also an integration gap. Even a perfectly specified circuit can be broken by the glue code that feeds it inputs. If the off-chain prover software applies different bounds-checking than the circuit assumes, an attacker who controls the prover (common in some rollup designs) can craft inputs the circuit was never designed to handle. The circuit is blameless. The system is compromised.
What a Real Detection Framework Looks Like
No single layer catches everything. The projects with the best track records layer their defenses, and in this writer's assessment, the ones that skip formal verification on the grounds of cost are making a bet they do not fully understand.
Circuit-level formal verification uses tools like Lean or Coq to prove that the constraint system is equivalent to a reference specification. Expensive and slow, but the only method that is actually exhaustive. Portions of Starkware's Cairo VM constraint system have been formally verified this way, and that matters more than any number of manual audit reports.
Invariant monitoring watches on-chain state for things that should be mathematically impossible: total supply exceeding the sum of all valid deposits and mints, for instance. Think of it as a smoke detector bolted to the outside of the proof system, indifferent to the circuit's internals. If a ZK rollup tracks net inflows from L1 and compares them to total L2 supply in a public dashboard, an inflation bug shows up as a discrepancy before anyone needs to understand the constraint system. Simple. Often neglected.
Economic circuit breakers pause the system when token supply changes by more than a plausible amount in a single block. This will not catch slow, small-scale inflation, but it contains catastrophic exploits before they drain the entire protocol.
Open-source provers matter more than people admit. If only one team can construct proofs, only one team can notice anomalous proof construction patterns. Multiple independent prover implementations create a cross-check that single-implementation systems structurally cannot have. Closed provers are not a security feature. They are a single point of failure wearing a nondisclosure agreement.
The Honest Position on Proof System Maturity
The field is young enough that the full taxonomy of ZK inflation bugs probably has not been written yet. Groth16 is battle-tested. PLONK and its variants are newer. Folding schemes like Nova are newer still. Each generation introduces constraint architectures that auditors are learning to reason about in real time, on live systems with real value at stake.
So ask yourself: if you were evaluating a ZK-based protocol today, what would you actually demand to see? The answer should include whether the circuit has been formally verified (not just audited), whether total supply is monitored on-chain as an invariant, and how the trusted setup was conducted, including where the ceremony transcript is published. These are answerable questions with documentary records, the kind of questions that belong in due diligence, not in a glossy whitepaper section on cryptographic soundness.
The cryptography in ZK systems is, largely, sound. The bugs live in the gap between what the math proves and what the protocol needs to be true. That gap is a design and engineering problem, and the teams that close it deliberately, through layered verification and public invariant monitoring, are building something meaningfully different from the teams that are simply trusting the proof.