Parag Mali - tag: zk-snarks

How Zero-Knowledge Broke in Real Life: Under-Constrained Circuits and the Bugs That Minted Money

noreply@paragmali.com (Parag Mali) — Fri, 24 Jul 2026 00:00:00 GMT

Zero-knowledge proofs now secure billions in rollups and bridges -- and every time one has *publicly* broken, the cryptography held. The failures were soundness bugs in the human-built artifact: a circuit missing a constraint, a verifier mishandling a zero, or a Fiat-Shamir transcript that hashed too little -- each letting a prover convince an honest verifier of something false. This is the documented record: Zcash's counterfeiting flaws, Dark Forest's range-check omission, the Frozen Heart disclosures, Solana's ZK ElGamal near-miss, the 2026 zkVM transcript breaks, the Veil Cash and FOOMCASH Groth16 exploits that actually moved money, and the adjacent BNB bridge theft. Why is this one bug family so easy to introduce, so hard to catch -- and what does the industry now build to hunt it? The through-line: the crypto held; the code didn't.

1. A Proof of Something That Was Not True

In June 2025, security researchers sent Solana's engineers a quiet, alarming message. The blockchain's on-chain ZK ElGamal Proof program -- the component that checks zero-knowledge proofs behind Token-2022 confidential transfers -- would accept a proof of something that was not true. The post-mortem stated the consequence plainly: a sophisticated attacker could forge a proof enabling "minting unlimited tokens or draining a victim's confidential balance" [@solana-june-2025].

No elliptic curve had been solved. No hash had been reversed. The discrete logarithm was exactly as hard the morning after as the morning before. What went wrong was smaller and stranger than any of that. In the program's own words, "a component was not included in a hash used to generate a transcript for the Fiat-Shamir Transformation" [@solana-june-2025]. One algebraic value was left out of a single hash, and that omission was enough to forge a proof the verifier would wave straight through.

"...minting unlimited tokens or draining a victim's confidential balance ... There is no known exploit." -- Solana ZK ElGamal Proof program post-mortem, June 2025

Read the last clause of that quote carefully, because it governs everything that follows. There is no known exploit [@solana-june-2025]. The bug was reported and disclosed responsibly, confidential transfers were disabled on June 11, and the proof program itself was disabled at the start of mainnet-beta epoch 805 on June 19 [@solana-june-2025]. The feature was still in testing, and no real funds moved. This was a near-miss, not a heist.

In a proof system, *soundness* is the guarantee that no one can produce a convincing proof of a false statement. A cheating prover cannot make an honest verifier accept a claim that is not true, except with negligible probability. Every failure in this article is a soundness failure: a valid-looking proof of something that was not so.

That distinction -- between a proof of a true thing and a proof the verifier merely accepts -- is the property under attack in every incident here. When it fails, we say the system has lost soundness.

Note: Every incident below carries a disposition tag, and the differences are load-bearing. A near-miss was disclosed and patched with no known exploitation -- present in shipping code, never turned into stolen funds. An exploited-then-recovered bug did move value on-chain, but the funds were returned or white-hat-rescued, so the net loss was small or zero. A confirmed theft moved value that stayed gone. And a reported incident is one where money moved but the zero-knowledge root cause rests on a security firm's characterization, with no primary post-mortem yet. Almost every clean zero-knowledge circuit failure on record is a near-miss; every confirmed theft, as we will see, lives in a verifier, a settlement boundary, or integration code -- and the largest was an adjacent kind of bug entirely.

Here is the thesis in miniature, and it inverts the headline you would expect. Solana's flaw is not an anomaly -- it is the signature of how zero-knowledge breaks in real life. Picture the system as two layers. Underneath sits a cryptographic hardness floor: the discrete-log-type and pairing-based hardness assumptions -- formally argued in the generic group model -- together with the collision-resistant hashes that proofs rest on.

Stacked on top is a human-built artifact: the construction, the circuit, the verifier, the transcript. In every publicly disclosed failure, the floor held. The artifact above it leaked. And where that artifact guarded a rollup or a bridge, the leak was denominated in money.

This piece is the documented record of that pattern -- the empirical mirror of its structural sibling, A Valid Proof of a False Thing, which derives why these proofs can break, and a companion to Never Decrypted: Proving You Ran the Computation, which shows how the proof systems are built in the first place. Here we do neither the derivation nor the construction. We read the ledger.

No cryptography broke -- so what, exactly, did? To answer that, we have to go back to the first time real money sat behind a shipping zero-knowledge system.

2. The First Silently Forgeable Proof

On March 1, 2018, Ariel Gabizon -- a cryptographer then at the Electric Coin Company, which builds Zcash -- found something disquieting in the paper Zcash had launched on. The privacy coin's proving system was a variant, known as BCTV14, of an earlier protocol called Pinocchio [@bctv-2013-879, @pinocchio-2013-279]. Gabizon discovered "a subtle cryptographic flaw" in it [@ecc-zcash]. Not in the hardness of the pairings the proofs relied on, but in the construction wrapped around them.

A **common reference string (CRS)** is a set of public parameters, produced once in a trusted setup, that both prover and verifier consult. In a pairing-based SNARK it encodes the circuit's structure as elliptic-curve group elements. If the CRS exposes elements it was supposed to withhold, a prover can turn them against the system -- which is exactly what happened to Zcash.

The flaw was specific. Pinocchio's template deliberately left certain elements out of its public parameters; the BCTV14 variant put some of them back. Gabizon's write-up names the mechanism exactly: the construction included "redundant elements in the CRS ... which are vital not to expose," and their exposure let a prover create "a proof of knowledge for any public input given a valid proof for some public input" [@gabizon-2019-119]. In plain stakes, that is counterfeiting -- forging shielded Zcash out of nothing. The assigned CVE puts the consequence in a single sentence [@cve-2019-7167].

"...transform the proof of one statement into an ostensibly valid proof of a different statement, thereby breaking the soundness of the proof system." -- CVE-2019-7167

The company found no evidence anyone had used it. The bug was patched silently by the Sapling network upgrade, which activated on October 28, 2018, and disclosed publicly on February 5, 2019 [@ecc-zcash].The vulnerability ran on two clocks. It was exploitable for roughly two years -- from the Sprout launch in October 2016 until Sapling closed it on October 28, 2018 -- but secret for only about eleven months, from Gabizon's March 2018 discovery to the February 2019 disclosure [@ecc-zcash]. A long window of exposure, a short window of concealment. The first near-miss in a long line.

Zcash teaches the shape of the entire record. Separate two things that are easy to blur. Underneath any real proof system sits a hardness floor -- named, well-studied assumptions like the discrete logarithm and elliptic-curve pairings. A pairing here is the verifier's tool, the operation that checks the proof equation, not itself a hardness assumption. A Groth16-style SNARK's soundness is argued in the generic group model, an idealized setting in which the adversary may only combine group elements through the allowed operations [@groth16-2016-260].

On top of that floor, humans build an artifact: the construction, the circuit, the verifier, the transcript. Gabizon's flaw did not touch the floor. It lived in the construction -- the topmost, most human layer -- and his fix confirms the diagnosis: the corrected BCTV14 is provably sound "in the generic group model, when these elements are excluded from the CRS" [@gabizon-2019-119]. The math was fine; the wiring around it exposed something it should not have.

flowchart TD A1["Construction: CRS and proof-system wiring"] --> A2["Circuit: the statement compiled to field constraints"] A2 --> A3["Verifier: the on-chain proof-checker"] A3 --> A4["Transcript: the Fiat-Shamir challenge hash"] A4 --> F1 subgraph FLOOR["Hardness floor (generic group model) -- unbroken in every disclosed case"] F1["Discrete-log and pairing hardness, plus collision-resistant hashes"] end The 0xPARC ZK Bug Tracker files Zcash under "Trusted Setup Leak" [@zk-bug-tracker], which sounds like toxic-waste retention -- someone kept the setup's secret trapdoor. The primary sources tell a different story. Gabizon and the Electric Coin Company describe a *redundant-CRS construction bug*: the setup published elements it should have held back, and no leaked trapdoor was needed [@gabizon-2019-119, @ecc-zcash]. Both failures live in the setup, but they are not the same failure. This article follows the primaries and keeps the two distinct.

The same shielded-Zcash counterfeiting signature returned almost exactly eight years later, one artifact layer down. In late May 2026, Taylor Hornby, working for Shielded Labs, found an under-constrained element in the newer Orchard circuit -- the shielded pool that succeeded Sapling -- that made it "possible to put arbitrary false inputs into an elliptic curve multiplication and still have the multiplication check pass" [@shieldedlabs-orchard]. A complete exploit generated "unlimited, undetectable counterfeit ZEC" in a local regtest [@forum-zcash-orchard].

The gap had been latent from Orchard's activation in May 2022 until an emergency fix on June 1, 2026 -- roughly four years -- and because Zcash's privacy hides transaction values, there is "no definitive way to determine using only cryptography whether such exploitation occurred" on mainnet [@forum-zcash-orchard]. A near-miss that rhymes with 2018 down to the coin, and -- as Section 3 will show -- a textbook case of a bug you cannot test for, because the flaw is a constraint that was never written.The 2026 Orchard bug sits in a different layer from the 2018 flaw -- 2018 was a redundant-CRS construction bug, 2026 an under-constrained circuit gadget -- but the coin and the consequence are identical: counterfeit shielded ZEC from nothing. The discovery was AI-assisted, through a targeted review of the Orchard circuit [@shieldedlabs-orchard]. It stays a near-miss: proven in regtest, never confirmed on mainnet [@forum-zcash-orchard].

Two catalogs make the rest of this record legible, and both recur below. The first is the 0xPARC ZK Bug Tracker, the canonical community catalog of zero-knowledge bugs found in the wild, with its own taxonomy of failure modes [@zk-bug-tracker]. The second is the academic corpus: a 2024 systematization by Chaliasos and colleagues that analyzed 141 real-world SNARK vulnerabilities and asked what patterns they share [@chaliasos-sok-arxiv, @chaliasos-sok-usenix]. Between them, they let us treat "how zero-knowledge breaks" as an empirical question with an answerable shape.

flowchart LR Z["2018-19: Zcash counterfeiting -- construction"] --> D["2021: Dark Forest range check -- circuit"] D --> AZ["2022: Aztec 0-bug -- verifier"] AZ --> FH["2022: Frozen Heart -- transcript"] FH --> B["Oct 2022: BNB Token Hub -- adjacent Merkle verifier, CONFIRMED THEFT"] B --> S["2025: Solana ZK ElGamal -- transcript, near-miss"] S --> VG["Feb 2026: Veil Cash / FOOMCASH -- Groth16 verifier key, EXPLOITED then RECOVERED"] VG --> V["early 2026: six zkVMs -- transcript, near-miss"] V --> OR["June 4 2026: Zcash Orchard -- circuit, near-miss"] OR --> AC["June 14 2026: Aztec Connect -- circuit + settlement, CONFIRMED THEFT"] AC --> HK["July 3 2026: Hinkal -- verifier integration, REPORTED"]

Zcash's flaw was exotic -- a redundant element buried in a trusted setup. It would have been comforting if that were the whole story. Instead, as zero-knowledge spread from one coin to thousands of applications, the same kind of bug appeared everywhere -- and in a form so ordinary it hid in plain sight.

3. The Constraint That Was Never Written

Dark Forest is a fully on-chain, real-time strategy game -- a galaxy of planets settled on Ethereum, where players keep their coordinates secret and prove in zero knowledge that each move is legal. A move requires showing that a target coordinate lies inside the map's bounds without revealing where it is. Dark Forest's circuit did this with a RangeProof built on a standard library comparator [@df-blog]. The comparator looked right. It was not, and the bug was flagged by Daira Hopwood [@zk-bug-tracker].

An **arithmetic circuit** expresses a computation as equations -- additions and multiplications -- over the integers modulo a large prime. Compiled to a rank-1 constraint system (R1CS), it becomes a list of constraints, each of the form (linear combination) times (linear combination) equals (linear combination). A zero-knowledge proof convinces a verifier that the prover knows a *witness* -- an assignment of a value to every wire -- satisfying every constraint, while revealing nothing about it.

The subtlety is that a proof does not certify that a statement is true. It certifies that some witness satisfies the constraints that were actually written. If the constraints permit a witness the designer never intended, the proof will happily certify it.

A circuit is **under-constrained** when its equations fail to pin down a unique, legitimate witness -- when some assignment the designer never intended still satisfies every written constraint. The missing constraint is an *absence*: the equation that would have excluded the bad witness was simply never written.

The smallest illustration fits in one line. Suppose a circuit constrains $y \cdot y = x$ and treats $x$ as the output. Over a prime field, that equation has two solutions for most $x$: both $y$ and its negation satisfy it. The output does not determine $y$. That non-uniqueness -- one input, more than one satisfying witness -- is the algebraic signature of every under-constrained circuit.

{` // A tiny field: the integers modulo a small prime. const p = 23; const mod = (a) => ((a % p) + p) % p;

// A constraint that only says: y * y === x (mod p). // It pins down x from y, but never pins down which root y is. const x = 9;

// Search the whole field for values of y that satisfy the constraint. const witnesses = []; for (let y = 0; y < p; y++) { if (mod(y * y) === x) witnesses.push(y); }

console.log('Constraint: y*y === ' + x + ' (mod ' + p + ')'); console.log('Witnesses that satisfy it: ' + witnesses.join(', ')); console.log(witnesses.length + ' distinct witnesses, so the output does NOT determine y.'); // Both 3 and 20 (which is -3 mod 23) pass. The circuit is under-constrained. `}

Dark Forest's bug was this same shape, dressed in a range check.

A **range check** forces a value to lie in a bounded interval, usually by constraining it to fit in *n* bits. Field arithmetic wraps around modulo a large prime, so without a range check a value that looks small can secretly be enormous. A large share of under-constrained bugs are missing range checks.

Dark Forest v0.3 built its RangeProof on CircomLib's LessThan(n) comparator [@df-blog]. That gadget is only correct when its inputs are already known to fit in n bits -- it assumes the bound but does not enforce it.

The circuit never constrained its inputs to n bits, so an attacker could feed an oversized field element whose low bits looked in-range and satisfy a RangeProof for an out-of-range coordinate. The fix was to add Num2Bits bit-length checks on both inputs, forcing them into range before the comparison [@df-fix-commit].In Circom the assignment operators are not interchangeable. <== both assigns a value and adds a constraint tying it to the equation, while <-- and = only assign, producing a witness value with no constraint attached. A signal written with <-- and never separately constrained is invisible to the proof -- the classic way an intended constraint goes missing.

{` // CircomLib's LessThan(n) is only correct when BOTH inputs are < 2^n. // It decides a < b from the low n bits. If a caller forgets to constrain // the inputs to n bits (no Num2Bits), the gadget can be fooled.

const n = 8; // designed for values in 0..255 const bound = 100; // we want to prove: secret < 100

function lessThan_nbits(a, b) { const mask = (1 << n) - 1; // only the low n bits are meaningful return (a & mask) < (b & mask) ? 1 : 0; }

const honest = 42; // a legitimate in-range coordinate const oversized = 256 + 42; // 298: same low 8 bits as 42, but out of range

console.log('LessThan says 42 < 100 : ' + lessThan_nbits(honest, bound)); // 1, correct console.log('LessThan says 298 < 100 : ' + lessThan_nbits(oversized, bound)); // 1, FALSE but accepted console.log('298 is out of range, yet the range proof passes.'); console.log('The forgotten Num2Bits(8) on the input is the missing constraint.'); `}

flowchart TD IN["Attacker supplies an oversized field element as the coordinate"] --> RP["RangeProof calls LessThan(n) on the input"] RP --> ASSUME{"Is the input constrained to n bits?"} ASSUME -->|"No Num2Bits check (the bug)"| WRONG["LessThan reads only the low n bits, returns in-range"] ASSUME -->|"Num2Bits added (the fix)"| RIGHT["Oversized input rejected before comparison"] WRONG --> ACCEPT["Verifier accepts a proof for an out-of-range value"]

Now sit with why this is so hard to catch.

Key idea: You cannot unit-test the presence of a constraint you forgot to write. A test feeds the circuit an input, computes a witness, and checks that a valid proof results -- and it always does, because the illegitimate witnesses live in exactly the space the missing equation was supposed to forbid. Every positive test passes. The bug is an absence, and absences do not appear in a test that only exercises what is already there.

This was no one-off. The same absence recurs across production libraries -- unbounded remainders, unchecked range gadgets, and more -- catalogued in the next section [@zk-bug-tracker].

Different libraries, same shape: a value assigned but never pinned down. All of these were near-misses -- audit-caught or disclosed before any exploitation. But the pattern was now visible, and it was not going away.

The comforting response is "audit harder." Yet a missing constraint is an absence, and absences do not live in one place. To defend against them, you first have to see the whole artifact they can hide in.

4. Three Ways to Accept a Lie

If a circuit can forget a constraint, what else can? Walk up the artifact and each layer has its own way of certifying something false. There are three: the circuit, the verifier, and the transcript. Each has a signature failure, and each disclosed failure is the reason the next defense exists.

flowchart TD L1["Circuit layer: Dark Forest, Aztec nullifier, MACI -- a missing constraint or range check"] --> L2["Verifier layer: Aztec 0-bug, BNB Merkle -- the proof-checker itself accepts a forgery"] L2 --> L3["Transcript layer: Frozen Heart, Solana, zkVMs -- the Fiat-Shamir hash binds too little"]

The circuit forgets a constraint

This is the dominant class -- the $y \cdot y = x$ intuition, generalized across production code. Once you know to look for an absence, you start to find it everywhere:

BigInt arithmetic. A BigMod template left its output remainder unbounded, so the "remainder" could exceed the modulus [@zk-bug-tracker].
Circom-Pairing. The library never checked the outputs of its BigLessThan range checks -- Veridise's "million-dollar bug caught early," found during an audit before the code reached mainnet [@veridise-circom-pairing].
MACI 1.0. An under-constrained vote-validity check would have let a coordinator quietly censor targeted votes [@zk-bug-tracker].
MiMC. A hash value was "assigned but not constrained" -- = where <== was required [@zk-bug-tracker].
ZK Email. An under-constrained circuit enabled email-address spoofing [@zk-bug-tracker].
PSE, Scroll, and Polygon zkEVMs. The same family surfaced as missing-constraint and unbounded-remainder findings inside production rollup circuits [@zk-bug-tracker].

A **nullifier** is a unique tag a zero-knowledge system publishes when a secret note is spent, so the same note cannot be spent twice. Its security depends on being deterministic and unique. If the circuit fails to pin it down, one note can produce many nullifiers, and the double-spend guard evaporates.

The most vivid of the set is Aztec's nullifier bug. In Aztec 2.0, "the field element representing this position was not actually constrained to be 32 bits," a gap that would "allow the attacker to spend the same input multiple times" [@aztec-disclosure]. A double-spend, produced by a single missing bit-length constraint.The 0xPARC catalog does not date its individual entries, so several years in this under-constrained cluster are approximate -- Dark Forest around 2021, the rest grouped roughly 2021 to 2023 [@zk-bug-tracker]. The dates are soft; the pattern is not.

Every one of these is an absence. Every one was a near-miss -- caught in an audit or disclosed before exploitation.Not every "missing range check" is a soundness bug, and the distinction sharpens the point. Semaphore and its Zk-Kit dependency once shipped without a check that a proof input was smaller than the SNARK scalar-field order [@semaphore-issue-90, @zk-kit-issue-23]. But that check was in the smart contract, and its absence produced "a group that will always fail verification" -- valid proofs rejected, a group rendered unusable [@zk-bug-tracker]. That is a completeness or liveness failure -- a denial of service -- not a soundness forgery, and it was fixed by adding the missing bound [@semaphore-fix-91]. It belongs one layer up from the circuit-soundness absences in this section, and naming it that way is what keeps "every failure here is a soundness failure" honest.

The verifier itself is wrong

The **verifier** is the code that checks a proof -- on a blockchain, usually a smart contract or precompile. It is a *separate artifact* from the circuit that produced the proof. A flawless circuit can still be defeated by a buggy verifier, because the verifier can accept proofs the circuit's math would never have permitted. Two artifacts, two independent chances to be wrong.

Aztec's PlonK verifier, written in C++, accepted forged proofs when two proof elements were set to zero. The code recognized 0 as "not on the curve" yet did not reject it, then re-interpreted that same 0 as the point at infinity, which satisfied the final pairing equation. A point-at-infinity and zero-encoding inconsistency, living in the checker rather than in any circuit [@aztec-0bug, @zk-bug-tracker].

Note: It is tempting to reason: "the circuit was proven correct, so the system is safe." The verifier is a different program with different bugs. Aztec's circuit could have been perfect and its C++ verifier would still have accepted a forged proof. When money depends on a proof, the audited artifact must be the on-chain verifier, not only the circuit.

February 2026 then put that warning on-chain twice, in the first two known exploits against live zero-knowledge verifiers. Neither touched the circuit, the pairing, or the curve. Both hit a trusted setup that was never finished.

Groth16, like many SNARKs, needs a **trusted setup**: a one-time ceremony that derives the proving and verification keys from secret randomness that must then be discarded. Its ceremony has two phases -- a universal "powers of tau" (Phase 1) and a per-circuit contribution (Phase 2) that randomizes the key parameter $\delta$. Skip Phase 2 and the tooling ships a placeholder key in which $\delta$ still equals $\gamma$ -- a valid-looking default that verifies honest proofs perfectly and accepts forged ones just as happily.

Veil Cash, a Base privacy pool, deployed a Groth16 verifier at 0x1e65c075989189e607ddafa30fa1a0001c376cfd whose verification key had delta2 == gamma2: both were the BN128 G2 generator point [@darknavy-veil, @veilcash-poc]. In Groth16, $\gamma$ and $\delta$ play different roles and must be independent. DARKNAVY states the consequence directly: with delta == gamma, the proof element C can cancel the public-input term, letting an attacker make the pairing equation pass "for ANY public inputs without any witness" [@darknavy-veil].

Using fabricated nullifier hashes across 29 withdrawals of 0.1 ETH, an actor drained 2.9 ETH of the roughly 4.5 ETH sitting in the legacy pools [@darknavy-veil, @veilcash-poc]. The Groth16 mathematics held; the deployed verification key was wrong.

flowchart TD A["Developer runs the snarkjs setup but skips Phase 2, the delta contribution"] --> B["Verification key ships with delta and gamma both the G2 generator placeholder"] B --> C{"Does the pairing check still depend on the public inputs?"} C -->|"delta equals gamma (the bug)"| D["Pairing equation collapses into a tautology"] D --> E["Attacker forges a proof for any public inputs, with no witness"] E --> F["Mixer pays out: 29 forged withdrawals drain the pool"] C -->|"Phase 2 run, delta randomized (the fix)"| G["Forged proof rejected"]

Where does an identical, on-chain-verifiable mistake come from twice in one week? zkSecurity traced the shared root cause to the tooling. Both projects used Circom with snarkjs, and in both "something went extremely wrong in the setup phase ... They simply didn't have any contributions to the second phase of the setup ceremony" [@zksecurity-groth16]. snarkjs initializes a new key with gamma2 and delta2 set to the same placeholder -- the G2 generator -- and expects the developer to run snarkjs zkey contribute, the Phase-2 step that randomizes delta while leaving gamma alone.

Skip that one step and the key ships with delta = gamma = G2 generator, collapsing the pairing check into a tautology [@zksecurity-groth16].The bug is a missing ceremony step with a valid-looking default, which is exactly why it survives testing: honest proofs verify perfectly. zkSecurity shows the tell in one line -- run the snarkjs quick-start without the contribution step and jq '.vk_gamma_2' and jq '.vk_delta_2' print the identical BN254 generator [@zksecurity-groth16]. A reviewer who compares those two points catches the collapse before the verifier ever holds value.

Six days after Veil Cash, the identical bug was pointed at FOOMCASH, a larger "ZKProof-powered" lottery whose Groth16 verifier had shipped on both Ethereum and Base with gamma and delta set to the same point [@quillaudits-foom, @foomclub-poc].

QuillAudits puts the exposure at about $1.3M in FOOM on Ethereum plus about $316K on Base -- roughly $1.6M by that accounting -- drained by algebraically forged proofs "without possessing any legitimate deposits or private witness"; other trackers report the gross across both chains as high as about $2.26M [@quillaudits-foom, @rekt-unfinished]. CertiK diagnosed the delta2 == gamma2 collapse within hours, and BlockSec flagged the event as a "copycat" imitation of Veil Cash -- a published post-mortem turned into an attack blueprint inside a week [@rekt-unfinished].

Here the disposition tag matters as much as the mechanism, and it is the reason this cluster gets its own tier. Neither drain was a permanent theft. Veil Cash's funds were recovered in full: Decurity rescued the remaining pools, and the original actor returned the 2.9 ETH unprompted [@rekt-unfinished]. FOOMCASH was substantially white-hat-rescued -- about $1.84M, roughly 80 percent of the $2.26M gross -- and whether it was ever malicious is disputed across the primaries: zkSecurity states flatly that "some websites reported the issue as an attack, which was not the case," while QuillAudits frames the same event as a drain [@zksecurity-groth16, @quillaudits-foom, @rekt-unfinished].

What no source disputes is that a broken verifier moved real money on-chain. Tag both exploited-then-recovered -- a distinct middle tier, neither a clean near-miss nor a permanent theft. And note what the cluster does to the thesis: it sharpens it. No curve broke and no Groth16 theorem failed; the deployed verification key violated the $\gamma \ne \delta$ separation the theorem assumes, so this is a verifier mismatch, not a pure in-circuit under-constraint.

"The first two known exploits against live ZK circuits happened in the past week ... some websites reported the issue as an attack, which was not the case." -- zkSecurity, "The Groth16 Trusted Setup Exploit," 2026

On October 6, 2022, a verifier-layer failure produced the largest confirmed on-chain theft in this record -- and the largest ever traced to a proof-verification bug, one layer over from any zk-SNARK. The BNB Chain Token Hub bridge relied on a precompiled contract that verified IAVL Merkle inclusion proofs, a Cosmos-SDK proof format. As samczsun's analysis showed, the verification code validated the Merkle path against only one branch and skipped lpath.Right, letting an attacker splice in an empty "phantom node" so that a crafted proof reproduced the expected root and certified a cross-chain deposit that had never happened [@samczsun-bnb, @emilianobonassi-bnb].

The forgery minted roughly 2,000,000 BNB, nominally around $566 to $586 million; validators halted the chain before most of it escaped, limiting the funds bridged off BNB Chain to an estimated $100 million and up [@coinbase-bnb].The figure of about 2,000,000 BNB minted is consistent across write-ups; the nominal dollar value (~$566 to $586 million) and the amount successfully moved off-chain before the halt (reported between roughly $100 and $127 million) vary by source [@coinbase-bnb].

flowchart TD A["Attacker crafts a deposit that never happened"] --> B["Builds an IAVL Merkle proof for it"] B --> C["Splices in an empty phantom leaf node"] C --> D{"Does the verifier check both branches of the path?"} D -->|"Skips lpath.Right (the bug)"| E["Crafted proof reproduces the expected root"] E --> F["Bridge certifies the deposit, mints about 2,000,000 BNB"] D -->|"Checks both branches (the fix)"| G["Forged proof rejected"]

That was, and remains, the largest confirmed theft in this record. On June 14, 2026, a newer confirmed theft reached a zero-knowledge circuit. An attacker drained about $2.19 million from a deprecated, immutable Aztec Connect contract, RollupProcessorV3, in one atomic transaction [@slowmist-aztec, @newsbtc-aztec]. SlowMist's forensic post-mortem names the mechanism a ZK-rollup settlement-boundary bypass [@slowmist-aztec].

The shape is worth tracing. The rollup's proof committed to 32 public-input slots, but the Layer-1 settlement contract processed only the first, indexed by an attacker-controlled numRealTxs value read straight from calldata with no on-chain constraint [@slowmist-aztec, @cryptotimes-aztec]. Between the two counts sat a gap of unused slots, and SlowMist says the circuit constraint that gap slots' publicValue should be zero was "either bypassed or not imposed" [@slowmist-aztec].

So the attacker packed the gap with forged deposits, minted unbacked balance across fourteen processRollup calls -- seven mints, then seven withdrawals -- and cashed it out as real ETH, DAI, and wstETH [@slowmist-aztec, @cryptotimes-aztec]. SlowMist's summary is the thesis in a sentence: "when the ZK circuit constraint is missing, the L1 contract layer also fails to detect the issue" [@slowmist-aztec].

flowchart TD A["Attacker sets numRealTxs from calldata, no on-chain constraint"] --> B["ZK proof commits all 32 public-input slots"] A --> C["L1 settlement loop traverses only the first slot"] B --> D{"Circuit forces gap-slot publicValue to zero?"} D -->|"Either bypassed or not imposed"| E["Gap slots 2..32 carry forged deposits"] E --> F["Mint unbacked L2 balance across 14 processRollup calls"] F --> G["Withdraw real ETH, DAI, wstETH from L1"] D -->|"Constraint present (the fix)"| H["Gap slots forced empty, forgery rejected"] This record is non-exhaustive and still growing, so read it by category, not by count. The incident-by-incident accounting, with figures and disposition tags, is the ledger in the next section; what matters here is the shape of the conclusion: these are artifact and accounting failures, never a solved curve or a reversed hash.

The verifier can be wrong on its own. But there is a third layer, subtler than either the circuit or the checker -- the one that turned Solana's proof into a forgery, and the one with the longest history of quietly re-shipping.

The transcript hashes too little

The **Fiat-Shamir transform**, introduced by Amos Fiat and Adi Shamir in 1986, turns an interactive proof into a non-interactive one [@fiat-shamir-86]. It applies to *public-coin* protocols -- ones in which every message the verifier sends is nothing but fresh public randomness. Instead of waiting for that random challenge, the prover computes it as a hash of the conversation so far -- the *transcript*. Because the hash stands in for the verifier's coins, every public value must be fixed *before* the hash is taken; a hash is unpredictable, so the prover cannot steer it, as long as it covers everything it must.

That last clause is the whole ballgame.

**Strong Fiat-Shamir** hashes the domain separator, the statement being proved, and *every* public value into the challenge. **Weak Fiat-Shamir** hashes only some of them, often just the prover's first message. The gap is the vulnerability: if a public value is left out of the hash, a malicious prover can vary that value freely, grind until the challenge is favorable, and forge a proof. sequenceDiagram participant P as Malicious prover participant H as Fiat-Shamir hash Note over P,H: Weak FS hashes the commitment but omits a public value P->>H: Send commitment only H->>P: Challenge derived from too little P->>P: Vary the omitted public value, recompute Note over P: Grind until the challenge suits a false statement P->>H: Submit forged proof Note over P,H: Strong FS binds statement plus all public inputs, blocking the grind

In April 2022, Trail of Bits published a coordinated disclosure of exactly this mistake across three different proof systems -- Girault's proof of knowledge, Bulletproofs, and PlonK [@tob-frozenheart-p1].

"We've dubbed this class of vulnerabilities Frozen Heart. The word frozen is an acronym for FoRging Of ZEro kNowledge proofs." -- Trail of Bits, April 2022

The Bulletproofs instance was especially telling: it "stem[med] from a mistake in the original academic paper," whose authors had recommended an insecure Fiat-Shamir implementation that omitted a Pedersen commitment from the hash [@tob-frozenheart-bp, @bulletproofs-2017-1066]. That is the instance the class's CVE was filed against: CVE-2022-29566 names the Bulletproofs 2017/1066 paper, which "mishandles Fiat-Shamir generation because the hash computation fails to include all of the public values" [@mitre-cve-2022-29566, @cve-2022-29566]. The PlonK instances shared the same shape, leaving public inputs out of the transcript [@tob-frozenheart-plonk].The pitfall was not new. Bernhard, Pereira, and Warinschi had drawn the weak-versus-strong distinction a decade earlier and shown that the weak form broke the Helios electronic-voting system [@bpw-2016-771]. The same one-line omission then recurs across four eras: Helios in 2012, Frozen Heart in 2022, Solana in 2025, and six zkVMs in 2026.

This was a proactive disclosure: affected parties were notified and had remediated before publication. A near-miss, class-wide.

How common is the class? A peer-reviewed systematization by Dao, Miller, Wright, and Grubbs surveyed open-source code and found 36 weak Fiat-Shamir implementations affecting 12 different proof systems [@dao-2023-691]. Not an anecdote -- a recurring omission with a name.

And here the article's opening snaps shut. The Solana ZK ElGamal bug from June 2025 was this exact root cause: a component left out of the Fiat-Shamir transcript hash, following an earlier instance in the same program reported that May [@solana-june-2025, @solana-may-2025]. But the story did not stop at Solana. In early 2026 -- March, by the disclosure timeline that runs from the first report in September 2025 -- OtterSec published "Unfaithful claims: breaking 6 zkVMs," reporting the same omission one layer up, inside the verifiers of six production zero-knowledge virtual machines: Jolt, Nexus, Cairo-M, Ceno, Expander, and Binius64 [@osec-zkvms].

"...public-claim data was not always bound into Fiat-Shamir transcripts before challenge generation ... We are breaking soundness in all six systems." -- OtterSec, "Unfaithful claims: breaking 6 zkVMs," 2026

The public claim the proof was about -- the statement itself -- was not always hashed into the transcript before the challenge was drawn, exactly the ordering invariant the transform depends on. To make the break concrete, the researchers proved mathematically impossible statements -- a counterexample to Fermat's Last Theorem among them -- against reference implementations, noting that in a blockchain context such a forgery "could translate to receiving $1M out of thin air" [@osec-zkvms]. Every case was responsibly disclosed and fixed between September 2025 and March 2026, in reference and production code, with no realized on-chain theft -- a transcript-layer near-miss, six times over.

Trace the thread and you get four eras of one omission -- Helios in 2012 [@bpw-2016-771], Frozen Heart in 2022 [@tob-frozenheart-p1], Solana in 2025 [@solana-june-2025], and the zkVMs in 2026 [@osec-zkvms]. The same missing line of code, re-shipped for fourteen years, each time in a more powerful system than the last.

Three layers, three ways to accept a false proof -- and a pattern nagging underneath all of them. Every break we have seen has the same shape. What is it?

5. One Lens for Every Break

Line the incidents up -- Zcash, Dark Forest, Aztec, Frozen Heart, Solana, the 2026 zkVMs, and the BNB bridge next door -- and a single sentence explains all of them.

Key idea: Name the artifact layer -- construction, circuit, verifier, or transcript -- and you have named the break. Across the entire disclosed record, the cryptographic hardness floor never appears. No incident attacked the discrete logarithm, a pairing, or a hash. Every one attacked the human-built layer above them.

That is the whole thesis, stated as a sorting rule. It is falsifiable -- one confirmed break of the discrete-log or pairing assumption in a shipping system would refute it -- and so far nothing in the record refutes it.

Note: This is not only a reading of a handful of anecdotes. The SoK 2024 study of 141 real-world SNARK vulnerabilities found under-constrained circuits to be the single most prevalent category, and the disclosed corpus is overwhelmingly made of soundness bugs rather than privacy or completeness failures [@chaliasos-sok-arxiv, @chaliasos-sok-usenix]. The pattern the incidents suggest, the data confirms. And the record is non-exhaustive by design -- new incidents keep arriving -- so what holds is the invariant, not the count: the layer explains the break, every time.

You do not have to take the sorting rule on faith. Here is the ledger -- a non-exhaustive but growing record -- laid out so you can audit the claim yourself. Read the "layer" column and the "tag" column together: the clean pure-circuit cases are near-misses, the Groth16 verifier-key drains were exploited and then recovered, and every confirmed theft lives in a verifier, a settlement boundary, or integration code. BNB remains the largest confirmed theft.

Incident	Year	Artifact layer	Tag	What it enabled
Zcash counterfeiting	2018-19	Construction	Near-miss	Forge shielded coins from a redundant CRS
Dark Forest RangeProof	~2021	Circuit	Near-miss	Prove an out-of-range coordinate
Aztec 2.0 nullifier	~2022	Circuit	Near-miss	Spend the same note multiple times
Circom-Pairing	~2022	Circuit	Near-miss	Forge signatures on a pairing library
Aztec PlonK "0-bug"	~2022	Verifier	Near-miss	Accept forged proofs via a zero encoding
Frozen Heart (Bulletproofs, PlonK)	2022	Transcript	Near-miss	Forge proofs for false statements
Solana ZK ElGamal	2025	Transcript	Near-miss	Mint unlimited tokens or drain balances
Six zkVMs (Jolt, Nexus, Cairo-M, Ceno, Expander, Binius64)	2026	Transcript	Near-miss	Forge proofs by an unbound public claim
Zcash Orchard counterfeiting	2026	Circuit	Near-miss	Forge unlimited shielded ZEC via an under-constrained EC-mult gadget
BNB Token Hub	2022	Verifier (Merkle, adjacent)	Confirmed theft	Mint about 2,000,000 BNB via a phantom node
Veil Cash	2026	Verifier (trusted setup)	Exploited, recovered	Forge Groth16 withdrawals after `delta2 == gamma2`, drain 2.9 ETH, returned in full
FOOMCASH	2026	Verifier (trusted setup)	Exploited, recovered	Copycat Groth16 `gamma == delta`, about $2.26M gross, about 80 percent white-hat-recovered
Aztec Connect	2026	Circuit + settlement	Confirmed theft	Mint unbacked L2 balance through gap slots whose zero constraint was either bypassed or not imposed, drain about $2.19M
Hinkal	2026	Verifier integration	Reported	Reported proofless deposit accepted without a ZK proof, about $820K laundered

The money framing needs the same care. The artifact is what leaked, and where it guarded a rollup, a pool, or a bridge, the leak was measured in funds minted or drained. "The bugs that minted money" is discharged by reading the ledger by category, not by count: the permanent thefts are BNB Token Hub -- still the largest -- and Aztec Connect [@coinbase-bnb, @slowmist-aztec]; the Veil Cash and FOOMCASH verifier-key drains were exploited-then-recovered, not permanent theft [@darknavy-veil, @quillaudits-foom, @rekt-unfinished]; and Hinkal is reported, its "proofless deposit" root cause resting on a security firm's reading with a full post-mortem still to follow, its loss put at roughly $800,000 to $830,000, so this article uses about $820,000 [@dextools-hinkal, @cryptotimes-hinkal].

Every one reinforces the scoped claim rather than disturbing it: each is a verifier, settlement, trusted-setup, or integration mismatch. What the record still shows no confirmed theft of is the pure case -- an in-circuit under-constraint independent of any settlement, verifier, setup, or integration mismatch. That is not luck to rely on; it is a fact about the record, and the record is still short.

A lens that names every break is worth little if you cannot act on it. So the field built tools -- one for each layer. How well do they work?

6. How the Industry Hunts the Bug Now

Each defense in use today is a scar -- a direct response to a documented failure. Read them from most sound to most human, and keep one tension in view the whole way down. The tools that can prove a circuit is properly constrained cannot yet run on production-size circuits, and the tools that run on production-size circuits cannot prove anything. No deployed tool is both. Call it the sound-versus-scalable frontier.

Sound uniqueness verification

The flagship family targets the dominant bug class head-on.

**Formal verification** of a circuit proves a property holds for *all* possible inputs, rather than checking a few. For under-constraint, the property is *uniqueness*: every output signal is determined by the inputs, so no second witness exists. A sound tool either proves uniqueness or hands back a concrete counterexample -- two distinct witnesses for the same input, the $y \cdot y = x$ signature made mechanical.

The lineage runs from a first sketch to increasingly capable engines. Ecne was the first widely known open checker that R1CS outputs are uniquely determined by inputs [@ecne-github, @ecne-writeup].Ecne carries a caveat that sharpens what "sound" means: it is a partial prover. A false result "does not mean that the constraints aren't sound, it just means that Ecne is unable to prove" they are [@ecne-github]. Picus, CIVER, and ConsCS go further, returning an actual witness pair.

Picus / QED2 made it quantitative, pairing an SMT solver with uniqueness inference to either prove a signal is determined or return a two-witness exploit; it resolved about 70 percent of a 163-circuit Circom benchmark and found 8 previously unknown vulnerabilities [@picus-2023-512, @picus-github, @pldi23-picus]. CIVER checks uniqueness compositionally, verifying a gadget once and reusing it, from inside the Circom compiler [@civer-github]. ConsCS is the current accuracy leader on Circom, lifting the solved rate above 80 percent [@conscs-polyu]. And halo2-analyzer (also called korrekt) carries the whole approach beyond R1CS to Plonkish and Halo2 circuits [@halo2-analyzer-eprint, @halo2-analyzer-github].

The governing bound is negative and structural. What these tools actually decide is non-uniqueness: they search for a second, distinct witness that satisfies the same constraints on the same input, and that witness pair is the certificate. Finding one is an NP search, because R1CS satisfiability is itself NP-complete -- so a sound checker cannot also be complete and efficient on every circuit, barring $P = NP$ [@picus-2023-512].

Deciding uniqueness itself is harder still -- it asks both that a witness exists and that no second one does, which places it above NP, in the class of differences of NP sets; the canonical Unique-SAT problem there is complete under randomized reductions [@papadimitriou-yannakakis-1984, @blass-gurevich-1982, @valiant-vazirani-1986]. Either way the conclusion is the same and unavoidable: every tool in this family is sound but incomplete. It may answer "unknown" or time out. That is not an implementation gap; it is the shape of the problem.

flowchart LR subgraph SOUND["Sound: a clean result proves absence"] S1["Ecne, Picus, CIVER, ConsCS, halo2-analyzer -- run on gadgets"] end subgraph SCALE["Scalable: runs on hundreds of production circuits"] S2["ZKAP, Circomspect -- lint, but no proof of absence"] end S1 -. "no tool sits in both boxes" .-> S2

Scalable static analysis

When you cannot prove, you can still scan. ZKAP implements nine detectors over a circuit dependence graph and ran across 258 circuits from popular Circom projects, surfacing previously unknown vulnerabilities [@zkap-2023-190, @zkap-usenix]. Trail of Bits' Circomspect is a linter that flags the tell-tale patterns -- a signal assigned with <-- but never constrained with <==, or an output left unconstrained [@circomspect]. Both scale to hundreds of circuits, and both are unsound: a clean scan means "no known-bad pattern found," not "no bug."

Prevention and the human net

Two more defenses sit at the ends of the spectrum. At the preventive end, strong-Fiat-Shamir transcript libraries bind the domain separator, the statement, and every public input by construction, removing the avoidable Frozen Heart class before it can be written. The 2026 zkVM breaks named the state-of-practice version precisely: merge the proof and transcript so every value the prover sends is absorbed before any challenge is drawn -- "Halo2 follows this pattern, and Binius is transcript-centric as well," though even transcript-centric Binius still missed binding the statement [@osec-zkvms].

Alongside it sits a newer, humbler discipline: trusted-setup ceremony hygiene as a shipped step -- confirming the deployed verification key actually finished Phase 2, with $\delta$ independent of $\gamma$, before it holds value. That is prevention by checklist, not a formal tool, but it is exactly the gap Veil Cash and FOOMCASH walked through, and a one-line check would have closed it [@zksecurity-groth16].

At the human end sit specialist audits and bug bounties -- the last net, and the one that actually caught the headline cases. The Solana report arrived through disclosure; so did the BNB analysis and the 2026 Groth16 drains [@solana-june-2025, @rekt-unfinished]. Firms like Veridise operationalize the sound branch commercially, folding uniqueness checkers into human audits of Circom, Halo2, and other circuits [@veridise-audits].

Note: Run a fast linter (Circomspect, ZKAP) on every commit to catch the obvious absences [@circomspect]. Reserve sound uniqueness checkers (Picus) for the small, high-value gadgets where a proof of absence justifies the runtime [@picus-github]. Before deployment, confirm the trusted setup actually finished -- that the verification key's $\delta$ is not still equal to $\gamma$ [@zksecurity-groth16]. Commission a specialist audit before mainnet, and keep a bounty live afterward -- it is how the Solana bug surfaced [@solana-june-2025].

So we have sound tools that do not scale and scalable tools that are not sound. Which philosophy should a team betting real money actually trust?

7. Four Philosophies, No Winner

This is where the zero-knowledge security community actually argues. Not over which tool is best -- over which kind of tool deserves your trust when funds are on the line. Four camps coexist, and the honest answer is that none of them wins outright.

The first axis is soundness versus scale, which we have already met. Sound formal tools like Picus prove output uniqueness or hand you a two-witness exploit, but only on gadgets; scalable analyzers like Circomspect and ZKAP run across whole projects but can only flag patterns they already know.

The second axis is prevention versus detection: strong-Fiat-Shamir libraries and constraint-safer languages try to make a class of bug unwritable, while linters and verifiers hunt bugs in artifacts that already exist.

The third axis is human versus automated versus economic: an expert audit reasons about intent, a tool reasons about rules, and a bug bounty pays outsiders to find what both missed.

Approach	Sound?	Scales?	Prevents or detects	Catches	Misses	Example
Sound uniqueness verification	Yes	No	Detects	Under-constrained circuits, with a counterexample	Anything past its timeout; non-circuit layers	Picus
Static analysis / linting	No	Yes	Detects	Known-bad patterns across many circuits	Novel absences it has no rule for	Circomspect, ZKAP
Strong Fiat-Shamir by construction	n/a	Yes	Prevents	The avoidable weak-transcript class	Circuit and verifier bugs	Strong-FS libraries
Expert audit	No	Partly	Detects	What a skilled reviewer reasons through	What the reviewer never thinks to check	Veridise
Bug bounty	No	Yes	Detects after ship	Bugs a motivated outsider finds	Everything, until value is already at risk	Solana, BNB disclosures

Read the table as a set of holes, not a ranking. The sound tools miss everything past their timeout and every layer that is not the circuit. The linters miss the novel absence they have no rule for. Prevention closes only the class it was designed for. Audits miss what the auditor does not think to check. And a bounty, by definition, reports a bug that already shipped.

The Veil Cash-to-FOOMCASH sequence makes the sharpest case against trusting any single net. The first drain was disclosed with a full technical write-up; six days later the same broken pattern was aimed at a larger target, so a published post-mortem had become an attack -- and rescue -- blueprint inside a week [@zksecurity-groth16, @rekt-unfinished].

When a bug class's signature is a missing step with a valid-looking default, it is trivially easy to reintroduce and just as easy for a copycat to find once the first case is public. Detection after the fact cannot keep pace with that; only prevention -- a Phase-2 check on every deployed key -- gets ahead of it.

Note: Both the Solana and BNB reports arrived through disclosure -- which is to say, after the code was live [@solana-june-2025]. The 2026 Groth16 drains are the sharper lesson: white-hats returned most or all of the money, but only after the broken verifier had already moved it on-chain [@rekt-unfinished]. A bounty is the last line, and a necessary one, but a bug caught by a bounty is a bug that was already exposed. Treat it as a safety net under the other defenses, never as a substitute for them.

Because the bug is an absence, and absences spread across three layers, no single method can promise to catch them. So the working consensus is not a winner but a discipline: defense-in-depth, one net per bug type. Lint every commit, prove the gadgets, prevent the avoidable class by construction, audit before mainnet, and keep a bounty live after. Each net has holes; the bet is that the holes do not line up.

Defense-in-depth buys coverage, not certainty. Push on why no single tool closes the gap, and you hit something deeper than engineering effort -- a wall.

8. Why You Cannot Test It Away

Suppose every team ran every tool on this list. The bug class still would not disappear -- and the reasons are theorems, not to-do items.

The first ceiling is the one we met in Section 3, now stated in full generality. A missing constraint is an absence, not a behavior you can enumerate. Testing samples witnesses and checks that valid ones produce valid proofs; but the illegitimate witnesses live in exactly the region the missing equation was supposed to forbid, so no finite suite of positive tests ever reaches them. You cannot sample your way to a constraint that is not there.

The second ceiling is the sound-versus-scalable frontier, and it is structural rather than temporary. Detecting under-constraint means searching for a second, distinct satisfying witness -- an NP-hard search, since R1CS satisfiability is NP-complete -- so a sound checker cannot also run efficiently on every input, and deciding uniqueness outright is harder still [@picus-2023-512, @papadimitriou-yannakakis-1984].

Production circuits are enormous; sound tools resolve gadgets and time out on the rest, which is why roughly a third of even a modest 163-circuit benchmark went unresolved [@picus-2023-512]. Verify gadgets, not whole zkEVMs -- not because the tools are immature, but because the problem is hard in the complexity-theoretic sense.

The third ceiling sits beneath even a perfectly constrained circuit. The Fiat-Shamir transform has no general, unconditional standard-model soundness guarantee for the succinct arguments that SNARKs compress: Goldwasser and Tauman Kalai showed in 2003 that the methodology can be uninstantiable there, with no guarantee that any concrete hash makes it sound [@gk-2003-034].

The scope of that claim is worth stating exactly, because it is easy to overstate. For a broad class of public-coin interactive proofs -- the trapdoor Sigma-protocols -- Fiat-Shamir is provably sound in the standard model, through correlation-intractable hash families built from the plain Learning-With-Errors assumption [@clw-2018-1248, @peikert-shiehian-2019-158]. But those results instantiate a concrete hash inside a common reference string and cover statistically sound proofs; they do not reach the succinct arguments, compiled under the random-oracle heuristic, that shipping SNARKs use -- which sharpens the point rather than softening it.

And the risk is not academic: in 2025, Khovratovich, Rothblum, and Soukhanov exhibited a practical Fiat-Shamir break on a widely studied GKR-based argument, holding "for every choice of FS hash function" [@khovratovich-2025-118]. Strong Fiat-Shamir removes the avoidable class -- forgetting to hash a public value -- but not the heuristic risk underneath it.

A fourth, quieter limit runs in the same spirit. In the plain model, with no common reference string or random oracle, non-interactive zero-knowledge exists only for languages a verifier could already decide on its own (Goldreich and Oren, 1994), so a hard-language SNARK can relocate its trusted setup but never remove it [@goldreich-oren-1994]. The 2026 delta == gamma drains are that theorem's practical mirror: a setup cannot be wished away, only executed correctly -- and a skipped Phase-2 step is not an abstraction but a live money bug [@zksecurity-groth16].

Key idea: The ceiling is a set of theorems, not a backlog. You cannot test an absence away, because a test only exercises what is present. No tool is both sound and scalable, because detecting under-constraint inherits NP-hardness. Strong Fiat-Shamir removes the avoidable mistake without removing the heuristic beneath it. And the trusted setup can be moved but not eliminated. Better tools will help. They will not make the bug class vanish.

The full derivations belong to the structural sibling, [*A Valid Proof of a False Thing*](/blog/a-valid-proof-of-a-false-thing-how-zero-knowledge-proofs-act/): why Fiat-Shamir is uninstantiable in the standard model for the arguments SNARKs use [@gk-2003-034], how a 2025 result forges proofs on a GKR-based argument for every choice of hash function [@khovratovich-2025-118], and why the plain model forces a setup at all [@goldreich-oren-1994]. Two caveats travel with them. Strong Fiat-Shamir closes the mistake of forgetting a public value, not the heuristic risk itself. And the hardness floor is unbroken *so far*, not unbreakable: a STARK's post-quantum security is a conjecture, not a proof [@starks-2018-046], and a large enough quantum computer running Shor's algorithm is the one clocked risk to the pairing-based floor.

That last caveat is the article's other standing hedge. "The crypto never broke" is a statement about the record to date, not a permanence guarantee. The floor has held in every disclosed case. It has not been proven unbreakable, and one class of it -- the algebraic, pairing-based SNARKs -- has a known expiry condition if large-scale quantum computing arrives.

If the bug class cannot be eliminated, the work is never "done." It is managed. So where is that management still failing?

9. The Seams Still Open

The frontier is a list of gaps everyone in the field can name.

The first is scaling sound verification. The unresolved tail of the uniqueness checkers -- the roughly one-third of circuits that time out -- is not random. It is exactly the large, non-linear region where production zkEVMs live [@picus-2023-512]. Closing that tail would move sound verification from gadgets to the systems that actually hold billions, and no one yet knows how.

The second is portability across representations, and it stopped being hypothetical in 2026. Most sound tooling grew up on Circom and R1CS, but the industry has moved to Plonkish arithmetization, AIR, and full zkVMs. When OtterSec broke six of those zkVMs through unbound Fiat-Shamir transcripts, none of the deployed uniqueness or anti-pattern tools would have caught it: they hunt a missing algebraic constraint over circuit signals, while this was a transcript-ordering defect one layer up, in the verifier's absorb-then-challenge sequence [@osec-zkvms].

The construction-side answer is emerging -- a 2026 framework shows how to compose a special-sound polynomial protocol with a suitably binding commitment so that applying Fiat-Shamir yields a tightly knowledge-sound SNARK [@eprint-2026-326]. But the detection-side analogue -- a sound automated checker for transcript binding in arbitrary zkVM verifier code, the Picus of the Fiat-Shamir layer -- does not yet exist, and testing cannot stand in for it: honest unit tests run the honest prover, and only manual analysis catches the omission [@osec-zkvms].

The third is standardizing transcripts and disclosure. The Frozen Heart class exists partly because there was no agreed, hard-to-misuse convention for what a Fiat-Shamir transcript must bind. Strong-FS libraries and transcript-proof fusion help, but a genuinely standard transcript format -- and a shared norm for how ZK bugs are disclosed and dated -- is still forming.

Running parallel to these is a setup-side gap the 2026 drains exposed. Catching a mis-finalized trusted setup -- a verification key whose delta still equals gamma -- is trivial if you know to look, yet there is no standard, enforced pre-deployment gate that a shipped key actually completed its ceremony [@zksecurity-groth16]. That is a tooling-and-process gap, not a theoretical one, which is what makes it both fixable and, so far, unfixed.

The fourth is the hardest to see, because it is about the evidence itself.

Note: Every prevalence claim in this article -- including "under-constrained circuits are the most common bug" -- is drawn from the bugs that were found [@chaliasos-sok-arxiv]. The corpus is survivorship-biased by construction. It cannot count the bugs still sitting undisclosed in shipping code, and it cannot tell us whether the clean zero-knowledge record reflects genuinely sound systems or merely undiscovered ones. Read the whole article with that bound in mind.

Measuring true prevalence -- not just disclosed prevalence -- would require watching for bugs that were never reported, which is close to a contradiction. It may be the one open problem here that tooling alone cannot solve.

Underneath all four is a maturity gap. Circuits ship on product timelines; verification tools mature on research timelines. As long as the first clock runs faster than the second -- and it now ships whole zkVMs while the tooling is still learning to read them -- the record will keep adding near-misses, and the industry will keep hoping they stay near-misses.

None of that helps the engineer shipping a circuit this quarter. So here is what you can do today.

10. A Reviewer's Checklist

Everything above collapses into a handful of questions you can ask of any zero-knowledge system before it holds value. Ask them layer by layer.

Circuit. Is every signal constrained, not merely assigned -- is there any <-- or = without a matching <==? Is there a range or bit-length check on every input that needs one, before any gadget that assumes it? That single question would have caught Dark Forest, whose fix was exactly a pair of Num2Bits checks added ahead of a comparator [@df-fix-commit]. Is every uniqueness-critical value -- a nullifier above all -- constrained to a fixed length so it cannot take two forms [@aztec-disclosure]?

Verifier. Is the on-chain verifier itself the audited artifact, and is it correct at the edges -- point-at-infinity, zero encodings, on-curve membership? Aztec's circuit was not the problem; its C++ verifier accepting a zero was [@aztec-0bug].

Trusted setup. If the verifier is a Groth16-style SNARK, did its trusted setup actually finish -- is the verification key's delta independent of gamma, rather than the placeholder generator the two share before Phase 2? A one-line comparison of those two points would have caught Veil Cash and FOOMCASH before either held value [@zksecurity-groth16].

Transcript. Does the Fiat-Shamir transcript bind the domain separator, the statement, and every public input, before any challenge is drawn? This is the one-line question behind Frozen Heart, behind Solana's 2025 near-miss, and behind the 2026 zkVM breaks [@solana-june-2025, @osec-zkvms].

Settlement and integration. Does the on-chain settlement loop cover every public-input slot the circuit committed to, and is a proof actually verified on every path that moves value? Aztec Connect's L1 loop read only the slots up to an attacker-controlled count while the proof committed all 32, and Hinkal was reported to have accepted a deposit with no proof at all [@slowmist-aztec, @dextools-hinkal].

{` // A toy stand-in for a transcript hash: just concatenate the bound parts. function challenge(parts) { return parts.join('|'); }

const commitment = 'C'; const statementA = 'honest public statement'; const statementB = 'false statement the prover prefers';

// WEAK Fiat-Shamir: bind only the commitment. The statement is NOT bound. const weakA = challenge([commitment]); const weakB = challenge([commitment]); console.log('weak: same challenge for two statements? ' + (weakA === weakB)); // true -> the prover can swap the statement without moving the challenge.

// STRONG Fiat-Shamir: bind the statement and every public input too. const strongA = challenge([commitment, statementA]); const strongB = challenge([commitment, statementB]); console.log('strong: same challenge for two statements? ' + (strongA === strongB)); // false -> swapping the statement changes the challenge, blocking the forge. `}

{` // A Groth16 key that skipped Phase 2 ships with delta == gamma, both still // the G2 generator placeholder. Detecting it needs no pairing algebra -- just // a point-equality check: are the two verification-key points identical?

const G2_GENERATOR = [[10857046, 11559732], [8495653, 4082367]];

// A key that finished Phase 2: delta was randomized, so it differs from gamma. const goodKey = { vk_gamma_2: [[10857046, 11559732], [8495653, 4082367]], vk_delta_2: [[19824234, 55049283], [77712121, 30310670]], };

// A key that skipped Phase 2: delta is still the generator, equal to gamma. const brokenKey = { vk_gamma_2: G2_GENERATOR, vk_delta_2: G2_GENERATOR, };

function phase2Skipped(key) { return JSON.stringify(key.vk_gamma_2) === JSON.stringify(key.vk_delta_2); }

console.log('good key -- Phase 2 skipped? ' + phase2Skipped(goodKey)); // false console.log('broken key -- Phase 2 skipped? ' + phase2Skipped(brokenKey)); // true console.log('Equal gamma and delta means the verifier accepts forged proofs.'); `}

Then map the tools onto the layers. The point is not to run everything, but to run the right net at the right layer.

Bug class	Layer	Detect with	Prevent with
Assigned but not constrained	Circuit	Circomspect, ZKAP, Picus	`<==` discipline, uniqueness checks
Missing range / bit-length check	Circuit	Picus, ZKAP	`Num2Bits` on every bounded input
Nondeterministic nullifier	Circuit	Picus (uniqueness)	Constrain the tag to a fixed length
Verifier edge case (zero, infinity)	Verifier	Audit, differential testing	Encoding and on-curve checks
Weak Fiat-Shamir	Transcript	Audit, transcript review	Strong-FS library, transcript-proof fusion
Skipped trusted-setup Phase 2 (`delta == gamma`)	Verifier / setup	Compare `vk_delta_2` and `vk_gamma_2`	Run `zkey contribute`, confirm `delta != gamma`
Unchecked settlement slot / proofless path	Settlement / integration	Audit, differential testing	Settle every committed slot, verify a proof on every value path

Note: A clean Circomspect or ZKAP run means no known-bad pattern was found -- not that the circuit is sound [@circomspect]. Only a sound uniqueness checker, and only within its timeout, proves absence [@picus-github]. Never let a passing lint stage stand in for a proof that a constraint is actually present.

Given a `RangeProof` that calls `LessThan(64)` on an input, ask: where is that input constrained to 64 bits? If the only bit-length logic in the circuit lives *inside* `LessThan`, there is none -- the gadget assumes it. The fix is a `Num2Bits(64)` on each input before the comparison, which is exactly the commit Dark Forest shipped [@df-fix-commit]. The verifier-side analogue is just as mechanical: given a deployed Groth16 key, print `vk_gamma_2` and `vk_delta_2` and compare them. If they are the same point, Phase 2 was skipped and the verifier will accept forged proofs -- the Veil Cash and FOOMCASH bug in a single check [@zksecurity-groth16].

One last item belongs on any honest checklist: knowing when zero-knowledge is the wrong tool. A proof system adds a large, subtle artifact -- three layers, each independently fallible -- on top of whatever it protects. If a cheaper mechanism gives the same guarantee, the safest circuit is the one you never had to write.

A checklist is only as good as the misconceptions it clears. Here are the ones this topic breeds.

11. Questions the Record Answers

The topic breeds a handful of durable misconceptions. Here are the ones worth clearing.

Not on its own. Soundness is relative to the circuit's specification. A valid proof means *some* witness satisfied the constraints that were actually written. If a constraint is missing, an illegitimate witness qualifies, and the proof certifies something the designer never intended. The proof is honest about the constraints; the constraints may not be honest about the world. No. Every publicly disclosed case is an artifact-layer soundness bug -- in a circuit, a verifier, or a transcript. The discrete-log, pairing, and hash assumptions underneath never appear in the record, and the empirical corpus of 141 SNARK vulnerabilities is overwhelmingly made of these soundness bugs [@chaliasos-sok-arxiv]. Yes, more than once -- but the honest answer needs tiers. Every confirmed on-chain money loss traces to a verifier, settlement, trusted-setup, or integration mismatch rather than a pure in-circuit under-constraint [@samczsun-bnb, @slowmist-aztec, @darknavy-veil], while the pure in-circuit cases -- Zcash, Dark Forest, Solana's ElGamal program -- were disclosed-and-patched near-misses; the full incident-by-incident accounting, with figures and disposition tags, is the ledger above. No. It was a proactive, coordinated disclosure across Girault, Bulletproofs, and PlonK implementations; affected parties remediated before publication [@tob-frozenheart-p1]. The same weak-Fiat-Shamir omission has now recurred across four eras -- Helios in 2012, Frozen Heart in 2022, Solana's ZK ElGamal program in 2025, and six production zkVMs disclosed by OtterSec in 2026 -- and every instance was a disclosed near-miss with no known exploitation [@bpw-2016-771, @solana-june-2025, @osec-zkvms]. "In the wild" here means the weak transcript was present in shipping code, not that anyone forged a proof with it. Under-constrained circuits. In the SoK 2024 study of 141 real-world SNARK vulnerabilities, they were the single most prevalent category, in a corpus dominated by soundness failures rather than privacy or completeness ones [@chaliasos-sok-arxiv]. Only partly. Sound tools such as Picus prove output uniqueness or hand you a two-witness exploit, but they do not scale to production-size circuits [@picus-2023-512]. Scalable linters such as Circomspect and ZKAP run across whole projects but are unsound -- a clean scan is not a proof [@circomspect, @zkap-2023-190]. And none of them checks whether your *trusted setup* was actually finalized, the gap the 2026 Groth16 drains walked through [@zksecurity-groth16]. No deployed tool covers every layer, which is why the discipline is defense-in-depth. No. The structural sibling *derives* the mechanisms -- why a redundant CRS, a weak transcript, or an uninstantiable heuristic can break a proof. This article is the *documented record* of those mechanisms shipping, breaking, and being caught, tagged incident by incident.

Step back and the ledger reads the same from every angle. In each publicly disclosed failure of a production zero-knowledge system, the cryptographic floor held: no curve solved, no hash reversed, no pairing broken. The human-built artifact above it leaked -- a circuit missing a constraint, a verifier mishandling a zero, a transcript that hashed too little, or integration code that forgot to check the proof at all.

And where that artifact guarded a rollup, a pool, or a bridge, the leak was denominated in money: minted or drained in the near-misses, moved and then returned in the 2026 Groth16 drains, and stolen outright in the confirmed cases, with the largest still in the adjacent BNB Merkle verifier.No confirmed theft in this record is a pure zk-SNARK circuit break: BNB was a Merkle-proof verifier bug; Veil Cash and FOOMCASH were Groth16 verifier-key bugs; Hinkal was reported as a proofless-deposit integration bug; and Aztec Connect paired a circuit-side gap-slot problem with a settlement-layer flaw. That is the distinction this whole article has kept, so that "the bugs that minted money" never quietly becomes "zero-knowledge cryptography was broken."

The crypto held; the code didn't -- in every disclosed case, and so far.

That refrain carries its own hedge. "So far" is doing real work: the record is short, the corpus counts only the bugs that were found, and the floor is unbroken rather than unbreakable -- a STARK's post-quantum security is still a conjecture, and Shor's algorithm remains the one clocked risk [@starks-2018-046].

The honest claim is not that zero-knowledge cannot break at the math. It is that, to date, it never has -- and every time it broke in real life, the fault was a line of code a human forgot to write. To see why those mechanisms can fail, read the structural sibling, A Valid Proof of a False Thing; to see how the proof systems are built in the first place, read Never Decrypted: Proving You Ran the Computation.

A Valid Proof of a False Thing: How Zero-Knowledge Proofs Actually Break

noreply@paragmali.com (Parag Mali) — Mon, 20 Jul 2026 00:00:00 GMT

Production zero-knowledge proofs almost never break at the cryptographic hardness. Across the entire documented incident record, the discrete-log, pairing, and hash assumptions held. The breaks live one layer up, in the artifact humans compile: **under-constrained circuits** (a missing constraint lets a prover forge a valid proof of a false statement -- the single most prevalent bug class), **trusted-setup subversion** (whoever keeps the setup trapdoor can forge any proof), and the **Frozen Heart** class (a weak Fiat-Shamir transcript that hashes too little). Name the layer -- circuit, setup string, or transcript -- and you have named the break. Even a STARK's transparent, hash-based construction only sheds one seam while inheriting the others, and "post-quantum secure" remains a conjecture, not a proof.

1. A Valid Proof of a False Thing

A verifier checks a zero-knowledge proof and returns a single bit: true. Every pairing balances. Every hash matches. The discrete-logarithm assumption the whole scheme rests on was never in doubt. And yet the statement the proof certifies is false, the money it authorized has already left the vault, and no one broke any cryptography to make it happen.

That sentence should read like a contradiction. A proof is supposed to be a guarantee, and "verified" is supposed to mean "true." Dissolving the paradox is the entire project of this article, and the resolution is deceptively small: a proof is valid relative to the constraints someone wrote down, not relative to the truth they meant to capture.

A protocol that convinces a verifier a statement is true while revealing nothing beyond its truth. The word "argument" (as opposed to "proof") signals *computational* soundness: the guarantee holds against a prover with bounded computing power, which is the setting every deployed SNARK actually lives in.

If the constraints never force the prover to be honest about some value, then a proof that verifies is not a lie about the mathematics. It is an honest proof of the wrong statement. The verifier did its job perfectly. The specification it was checking simply was not the specification the designer had in mind.

Key idea: A verifying proof means "the prover found some witness the circuit accepts," not "the statement is true." Those two readings coincide only when the circuit was written to force them together. Every break in this article is a place where they came apart.

To see how that gap opens, picture a zero-knowledge system as two stacked layers.

flowchart TD subgraph Artifact["Human-built artifact -- where every break lives"] C[Arithmetized circuit] S[Trusted-setup string] T[Fiat-Shamir transcript] end Artifact --> Floor subgraph Floor["Hardness floor -- unbroken so far"] D[Discrete logarithm] P[Elliptic-curve pairings] H[Collision-resistant hash] end

At the bottom sits a hardness floor: a small set of problems believed intractable, such as computing discrete logarithms, solving pairing relations, or finding hash collisions. At the top sits a human-built artifact: an arithmetic circuit that encodes the statement, a setup string that parameterizes the system, and a Fiat-Shamir transcript that turns an interactive exchange into a single non-interactive proof. Cryptographers design the floor over decades and attack it relentlessly. Engineers assemble the artifact per project, often under deadline.

Here is the thesis this article defends, drawn from the documented vulnerability record rather than from any theorem: production zero-knowledge proofs almost never fail at the cryptographic hardness. They fail at soundness in the layer humans build [@sok24]. The floor has held in every deployed break on record. The three seams above it -- the circuit, the setup string, and the transcript -- are where the leaks happen, and this article anatomizes each one.

One boundary before we start. This is a structural teardown: we are after the ways the artifact itself is mis-designed. The separate world of implementation faults -- timing side channels, faulty randomness, nonce leakage -- is real and dangerous, but it belongs to a sibling article, "How Zero-Knowledge Broke in Real Life." Here, every bug we examine would still be a bug if the code ran on perfect hardware with a perfect random-number generator.

To understand why the floor and the seams are even separable -- why you can lose soundness while discrete logarithm stands untouched -- we have to go back to 1985, to the paper that first pulled a proof apart into three independent pieces.

2. Where Soundness Was Born

Before 1985, a proof was a static object. You held a witness -- a satisfying assignment, a factorization, a certificate -- and you handed it over. The verifier re-checked it and was convinced. Soundness in that world was absolute and fused to the statement: a false claim simply has no accepting witness, so cheating is impossible by definition.

But that same fusion meant there was no vocabulary for a cheating prover. You could not ask how much a liar might get away with, or measure it apart from the underlying hard problem. There was no "soundness error" to reason about, because soundness was all-or-nothing and welded to truth.

Shafi Goldwasser, Silvio Micali, and Charles Rackoff broke that object into pieces. Their 1985 paper on the knowledge complexity of interactive proof systems replaced the static witness with an interactive protocol: a prover and a randomized verifier trade messages, the verifier issues fresh unpredictable challenges, and it accepts only probabilistically [@gmr85].

In doing so they separated a proof into three properties that had never been named apart before -- completeness, soundness, and zero-knowledge -- and, decisively, they made soundness a quantity. A cheating prover now succeeds with some probability, the soundness error, that you can drive toward zero but analyze on its own terms [@gmr85].

A "proof" in the strict sense has soundness against a computationally unbounded cheating prover; an "argument" only against a bounded one. Almost every deployed SNARK is technically an argument. The distinction matters because argument soundness can rest on a hardness assumption, which is exactly the floor this article shows never cracks.

That separation is the hinge of everything that follows. Because soundness is measured against the statement as encoded, not against discrete logarithm, a proof can be cryptographically valid and still certify a falsehood -- the encoded statement was wrong, even though the mathematics behind it was pristine. GMR gave the field the language to say that sentence.

Then came two conveniences, each of which made proofs deployable and each of which opened a seam. In 1986, Amos Fiat and Adi Shamir showed you could remove the live verifier entirely [@fs86].

A method for making an interactive proof non-interactive by computing the verifier's random challenge as a hash of the conversation so far, rather than waiting for a human or a live party to supply it. The prover hashes its own commitment (and, done correctly, the statement) to derive the challenge, so anyone can recompute and check it offline.

The Fiat-Shamir transform is the universal glue beneath essentially every non-interactive proof and Schnorr-style signature in production -- and, as we will see, the exact step whose mis-implementation becomes the Frozen Heart class thirty-six years later. Two years after Fiat-Shamir, Manuel Blum, Paul Feldman, and Silvio Micali added the other convenience: a shared common reference string that lets a single message be a full zero-knowledge proof inside a security model rather than merely a heuristic [@bfm88]. Every later structured setup -- Groth16's reference string, the "powers of tau" ceremonies -- is a concrete descendant of that idea.

flowchart LR A[1985 GMR: three properties] --> B[1986 Fiat-Shamir transform] B --> C[1988 BFM setup string] C --> D[2012 Helios weak Fiat-Shamir] D --> E[2016 Groth16 toxic waste] E --> F[2019 Zcash redundant CRS] F --> G[2022 Frozen Heart] G --> H[2025 practical Fiat-Shamir break]

Could you simply delete the setup seam by using no setup at all? In 1994, Oded Goldreich and Yair Oren proved you cannot: non-trivial non-interactive zero-knowledge in the plain model, with no setup whatsoever, collapses to the class BPP -- meaning it buys you nothing beyond ordinary randomized computation [@go94]. A setup of some kind is mandatory. This theorem is why a careful engineer says a transparent system has "no trusted setup" and never "no setup." The distinction is load-bearing, not pedantic, and it will decide how we read STARKs later.

"Transparent" setup means the setup uses only public randomness that anyone can verify -- a public-coin setup -- so there is no secret trapdoor to leak. Goldreich and Oren [@go94] show you can downgrade a trusted setup to a public-coin one, but you can never reach no setup for a non-trivial statement.

Three properties, three ways to fail. Before we watch each one break in production, we need the grid that tells us which failure we are looking at -- and, more to the point, which one steals money.

3. Three Ways to Fail, One That Pays

A zero-knowledge system can fail along exactly three axes, because GMR gave it exactly three properties [@gmr85]. Only one of those failures makes an attacker rich. Getting clear on which is which is the analytical spine of everything that follows, so it is worth building the grid deliberately.

The guarantee that a cheating prover cannot convince an honest verifier of a false statement, except with negligibly small probability -- the soundness error. Soundness is the property an attacker attacks: break it and you can prove things that are not true. The guarantee that an honest prover holding a valid witness always convinces an honest verifier. A completeness failure rejects legitimate proofs. It denies service; it does not manufacture forgeries. The guarantee that a proof reveals nothing beyond the truth of the statement, formalized by a simulator that produces a transcript indistinguishable from a real one without ever seeing the witness. A zero-knowledge failure leaks the secret. It does not let anyone prove a falsehood.

Line those three up against their consequences and the asymmetry is stark.

Failure axis	What goes wrong	Consequence	Who attacks it
Completeness	Honest prover gets rejected	Liveness / denial of service	Usually no one -- it is a self-inflicted bug
Soundness	False statement accepted	Forgery, minting, theft	A malicious prover
Zero-knowledge	Witness is exposed	Privacy loss, de-anonymization	A malicious verifier or observer

Read the table as a threat model. A completeness failure is annoying but not lucrative: your honest users cannot get their valid proofs accepted, so the system grinds rather than bleeds. A zero-knowledge failure is a privacy catastrophe -- the secret the proof was meant to hide leaks out -- but it forges nothing; the attacker learns a witness, they do not mint one.

A soundness failure is the money axis. When a malicious prover convinces an honest verifier of something false, and that verifier is a smart contract that releases funds or mints tokens, the false statement becomes a withdrawal. This is why soundness is the axis attackers actually target, and the axis this article spends its time on.

The empirical record confirms the asymmetry rather than merely asserting it. The 2024 systematization of SNARK vulnerabilities examined 141 disclosed bugs and found that the overwhelming majority compromise soundness -- on the order of 95 of them -- while only a handful, around four, affect completeness [@sok24]. The disclosed corpus is, in effect, a ledger of soundness breaks. And these are not abstract failures.

"Several million dollars worth of cryptocurrency have been stolen due to underconstrained arithmetic circuits." -- the Picus/QED2 authors and the IACR announcement of their work [@picus23][@iacr20490]

Notice what that sentence does not say. It does not say the discrete-logarithm assumption fell, or that someone found a hash collision, or that a pairing was inverted. The theft came from circuits that were under-constrained -- a soundness failure in the arithmetization layer, the top of the stack, with the hardness floor entirely intact [@picus23]. That is the pattern in miniature, and we are about to see it three times over.

Every real break in the rest of this article lands on the soundness axis, and each one lives in a different layer of the artifact.

4. The Break Surface, Layer by Layer

The artifact humans build has three parts, and each one has failed in production. We will walk them from the top down: the arithmetization layer where a computation becomes equations, the setup layer where the system is parameterized, and the transform layer where an interactive proof is frozen into a non-interactive one. This is not a smooth ascent toward safety. It is the same small set of bugs reappearing as the systems industrialize, generation after generation.

Note: The next three subsections each take one layer, explain the mechanism precisely, and end at the failure that motivates the next. Keep one structural fact in view throughout: the seams are orthogonal. Fixing the circuit does nothing for the setup string; removing the trapdoor does nothing for the transcript. That independence is the observation the whole article turns on, and we will name it explicitly once all three are on the table.

We start with the arithmetization layer, the one that breaks most often and most expensively [@sok24].

4a. The Circuit -- Under-Constrained Arithmetization

Return to the forged proof from the opening. We can now say exactly what happened to it. Before a statement can be proved, it has to be compiled into a form a proof system understands, and that compilation is done by hand.

The compilation of a computation into a system of equations over a finite field. The most common target is a rank-1 constraint system, or R1CS: a long list of quadratic constraints, each of the form "one linear combination of the signals, times another, equals a third." The signals are the inputs, outputs, and intermediate values; "proving the computation" means exhibiting a signal assignment that satisfies every constraint at once.

A circuit, then, is a hand-written compiler artifact: the programmer's mental model of a computation, flattened into equations. That compilation has a lineage -- the quadratic-span-program and Pinocchio constructions turned a constraint system into a form a pairing can check in constant time, which is what made general-purpose SNARKs practical [@ggpr13][@pinocchio]. And like any hand-written artifact, it can be missing a line. What happens when the human forgets one of the equations?

A constraint system that admits more than one satisfying assignment for a signal the designer meant to pin down. Because several witnesses satisfy the same constraints, a prover can pick one the specification never intended and still produce a proof the verifier accepts.

That is the whole mechanism. A missing constraint means the system of equations has too much slack: the value the developer assumed was forced is actually free. A malicious prover fills that freedom with an out-of-spec value, satisfies every constraint that is present, and hands the verifier a proof that checks perfectly.

flowchart TD A[Computation compiled to a constraint system] --> B[One constraint omitted] B --> C{"More than one witness fits?"} C -->|Yes| D[Prover supplies an out-of-spec value] C -->|No| E[Output uniquely determined and safe] D --> F[Verifier accepts a valid proof of a false statement]

The canonical toy version is a square. Suppose you want to prove "I know the secret value the designer had in mind, and its square is x." The obvious constraint is that the square of the witness equals x. But that single equation does not pin the witness: in a field, both a root and its negation square to the same value, so two different witnesses satisfy one constraint. Run it and watch both slip through.

{` // A toy field-arithmetic "circuit" over the small prime p = 23. // Intended statement: "I know the specific value y the designer meant, // and its square is x." The circuit writes only ONE constraint: // x === (y * y) mod p // It never pins WHICH square root y is -- so the value is under-determined. const p = 23; const mod = (a) => ((a % p) + p) % p;

function circuitAccepts(x, y) { return mod(y * y) === mod(x); // the single constraint actually enforced }

const x = 4; // the public output the verifier sees const intended = 2; // the witness the designer assumed const forged = p - 2; // 21: a DIFFERENT witness, same constraint

console.log("intended y =", intended, "accepted:", circuitAccepts(x, intended)); console.log("forged y =", forged, "accepted:", circuitAccepts(x, forged)); // Both print true. A proof that "verifies" has not pinned the value the // specification intended -- it only certifies that SOME accepted witness exists. `}

In a toy square the extra witness is harmless. In a withdrawal circuit that was supposed to enforce "this note has not already been spent" or "this balance is non-negative," the extra witness is a second spend or a negative amount that verifies as valid -- a mint or a theft, produced without touching the cryptography underneath.

Note: A verifying proof certifies that the prover satisfied the circuit, not that they satisfied your specification. If a constraint you assumed is missing, the verifier will accept out-of-spec witnesses all day. "Valid" is a claim about the equations on the page, never about your intentions.

This is the payoff of the first aha moment. The naive reading -- "a verifying proof means the statement is true" -- fails because a verifying proof only means the prover found some witness the circuit accepts. When the circuit is under-constrained, that witness can be an out-of-spec lie, and the discrete-logarithm assumption is fully intact the entire time.

The archetypal way this bug enters real code is a one-character slip.

In Circom, the most widely used circuit language, <-- assigns a value to a signal but adds no constraint, while <== assigns and constrains. Writing <-- where you meant <== leaves the signal free -- the exact shape of an under-constrained bug. Trail of Bits built the Circomspect linter specifically to flag that slip and related unconstrained-signal patterns [@circomspect_gh][@circomspect_blog].

The field arithmetic hides further traps: values that alias modulo the field prime, and "hint" signals computed outside the circuit that are trusted without an in-circuit check. Each is a different way to leave a signal under-determined, and cataloguing them all is a project of its own. The structural point is singular: every one of these is a missing constraint, and a missing constraint is a soundness bug in the layer you wrote.

How prevalent is it? The 2024 systematization is blunt: across 141 disclosed SNARK vulnerabilities, under-constrained circuits are the single most prevalent class [@sok24]. This is not an exotic failure that shows up once a decade. It is the modal bug of the entire field, which is why it gets the most tooling -- and why we can catch it if we ask the right question.

The property you actually want is *determinism*: every output signal should be uniquely determined by the inputs. You can test it mechanically -- ask a solver whether two different witnesses can share the same inputs yet differ on an output. If the answer is yes, the circuit is under-constrained. That is exactly what the Picus/QED2 tool automates [@picus23], and Section 10 turns it into a concrete review step.

A missing constraint is a bug in a layer you wrote and can, in principle, read. But what if the flaw is baked into a string you were handed -- one you cannot even inspect, generated in a ritual you had to trust?

4b. The Reference String -- Trusted-Setup Subversion and Toxic Waste

Some of the most efficient proof systems need a one-time setup that samples secret numbers, uses them to build a public parameter string, and then -- supposedly -- destroys them. The whole security argument rests on that destruction actually happening. What if someone keeps a copy?

A structured reference string (SRS) is a setup string whose elements carry algebraic structure: they are group encodings of secret scalars sampled once at setup time. Only the encodings are published. The secret scalars themselves are the "toxic waste." Anyone who retains them holds a trapdoor that can forge a proof of *any* statement, because the trapdoor lets them satisfy the verification equation without a real witness.

This is the setup layer's first and cleanest failure mode, and Groth16 is its reference example. Jens Groth's 2016 construction produces the smallest proof among deployed pairing-based SNARKs -- three group elements checked by a single pairing-product equation [@groth16] -- and that compactness is exactly what makes it attractive for gas-sensitive on-chain verification. But its soundness depends on an operational assumption, not a cryptographic one: it assumes the toxic waste was destroyed [@groth16]. If it was not, the holder forges at will, and the pairing assumption underneath never budges.

flowchart TD A[Setup samples secret scalars] --> B[Publish only their group encodings as the SRS] B --> C{"Trapdoor destroyed?"} C -->|Yes, via ceremony| D[No one can forge, system is sound] C -->|No, someone kept it| E[Holder forges any statement at will]

This is why the ceremony matters. To avoid trusting a single party to destroy the trapdoor, the setup is run as a multi-party computation: each participant folds in fresh secret randomness and destroys their own share, and the forgery-enabling trapdoor is the product of all shares. It is unrecoverable unless every participant colludes, which flips the requirement into a reassuring form -- the setup is secure if at least one of the participants was honest [@eth_kzg_blog].

These are the "powers of tau" ceremonies, named for the secret scalar tau whose successive powers structure the string. The security property is the "1-of-N honest" assumption: among N contributors, a single honest one who truly destroyed their randomness makes the trapdoor unrecoverable [@eth_kzg_blog].

The modern scale of this is remarkable. Ethereum's KZG Summoning Ceremony ran for 208 days and collected 141,416 contributions, and its security rests on needing only a single honest participant among them [@eth_kzg_blog]. That turns an unavoidable trusted setup into a broadly auditable social process. The residual cost is real, though: the guarantee is social, never provable, and for Groth16 the ceremony is per-circuit -- every new program needs its own [@eth_kzg_blog].

Now the accuracy-critical part. There is a second, entirely different setup-layer failure that is routinely conflated with the first, and conflating them gets the physics wrong.

**Mode 1 -- toxic-waste retention.** Someone keeps the secret scalars a correct setup was supposed to destroy, and uses that trapdoor to forge. The construction is fine; the secret leaked. The ceremony is the defense.

Mode 2 -- a construction soundness bug. The setup string itself is built wrong -- it contains elements that should not be there -- so a prover can forge even though no secret was ever retained. No ceremony helps, because nothing leaked. The construction is the defect.

Mode 2 is what actually happened to Zcash. The SNARK it deployed, BCTV14, carried redundant elements in its reference string that the earlier Pinocchio template had deliberately excluded [@gabizon19][@bctv14]. Ariel Gabizon showed those redundant elements let a prover convert a valid proof of one statement into a valid-looking proof of a different statement -- undetectable, unlimited counterfeiting, with the hardness assumption completely intact [@gabizon19].

The flaw let an attacker "transform the proof of one statement into an ostensibly valid proof of a different statement, thereby breaking ... soundness." -- the official record of CVE-2019-7167 [@cve19]

The timeline is the quietly alarming part, and it hides two windows that are easy to conflate. The Electric Coin Company's postmortem records that the flaw was discovered on 1 March 2018, silently remediated by the Sapling network upgrade that activated on 28 October 2018, and only disclosed on 5 February 2019 [@ecc19].

Those two windows are very different lengths. The exploitable window was the long one: the flaw was present from Zcash's 2016 launch until the Sapling fix, roughly two years in which the currency was silently, undetectably counterfeitable. The secrecy window was only the eleven months from private discovery to public disclosure. Across both, no observer could have told from the chain, because a forged proof under this bug looks exactly like an honest one [@ecc19]. Groth16's minimal reference string removed this entire class by construction, because it contains only the elements the proof actually needs [@groth16].

Note: The Zcash counterfeiting flaw was not a leaked secret and not a failed ceremony. It was a soundness bug in how the reference string was built [@gabizon19][@cve19]. Filing it under "toxic waste" hides the lesson: even a setup whose secrets were perfectly destroyed can be forgeable if the string is structured wrong.

Both setup failures, though, share one escape hatch: they vanish entirely if you have no trusted setup at all. Draw every parameter from public randomness and there is no trapdoor to keep and no structured string to get wrong. Bulletproofs does exactly that -- and Bulletproofs was still forged. The trapdoor, it turns out, was never the only seam.

4c. The Transcript -- The Frozen Heart

The Fiat-Shamir transform is the glue that makes proofs non-interactive, and its soundness hangs on a single question: what goes into the hash? Get that wrong and the whole non-interactive proof becomes forgeable, no matter how strong the hash function is.

Weak Fiat-Shamir derives the challenge from the prover's commitment alone -- the challenge is a hash of the commitment. Strong Fiat-Shamir binds the challenge to everything that should matter: a domain separator, the statement, all public inputs, and the full transcript. The entire difference is *what enters the hash*, and it is the difference between a sound proof and a forgeable one.

Here is why the omission is fatal. In a three-move protocol, a simulator that is handed the challenge in advance can fabricate a convincing commitment-and-response pair with no witness at all. That capability is a feature -- it is precisely what makes the protocol zero-knowledge.

Weak Fiat-Shamir accidentally hands the attacker the same capability. If the challenge is a hash of the commitment only, a malicious prover can work backwards: choose values so the verification relation holds, for a statement that is false. Because the statement and its public inputs never entered the hash, the transcript no longer pins down which statement is being proved. What the attacker can reach is protocol-dependent: a random or attacker-derived statement in the general case, and in systems like the Bulletproofs range proof a chosen out-of-range value -- the case that turns the flaw into forged money.

flowchart TD subgraph Weak["Weak Fiat-Shamir"] W1[Challenge hashes the commitment only] --> W2[Attacker fixes the challenge first] W2 --> W3[Back-fills a bogus commitment and response] W3 --> W4[Forged proof verifies] end subgraph Strong["Strong Fiat-Shamir"] S1[Challenge hashes statement, inputs, transcript] --> S2[Challenge pinned to the statement] S2 --> S3[No freedom to back-fill] S3 --> S4[Forgery blocked] end

The tell is that the challenge is identical for two different statements under weak Fiat-Shamir, so a transcript built for one carries over to another. Watch it happen.

{` // A stand-in hash (FNV-1a). Not cryptographic -- illustrative only. function H(s) { let h = 2166136261 >>> 0; for (const ch of String(s)) { h = Math.imul(h ^ ch.charCodeAt(0), 16777619) >>> 0; } return h >>> 0; }

// Two DIFFERENT statements a prover might try to prove. const statementA = "pubkeyA-owns-100"; const statementB = "pubkeyB-owns-100"; const commitment = "prover-first-message";

// WEAK Fiat-Shamir: the challenge ignores the statement entirely. const weakA = H(commitment); const weakB = H(commitment); console.log("weak FS -- same challenge for A and B?", weakA === weakB); // true

// STRONG Fiat-Shamir: the challenge binds statement + inputs + transcript. const strongA = H(statementA + "|" + commitment); const strongB = H(statementB + "|" + commitment); console.log("strong FS -- same challenge for A and B?", strongA === strongB); // false `}

Under weak Fiat-Shamir the challenge is the same for statement A and statement B, so any freedom the prover has to satisfy the relation for that one challenge value is not tied to a particular statement -- they can retarget it to a false claim. Strong Fiat-Shamir makes the challenge a commitment to the statement itself, so that freedom is pinned and the retargeting fails.

This is not a hypothetical, and it is not a one-off. It is the same bug across three eras. In 2012, David Bernhard, Olivier Pereira, and Bogdan Warinschi named the weak-versus-strong distinction and used it to break Helios, a real electronic-voting system that hashed the commitment but not the statement [@bpw12]. A decade later, in April 2022, Trail of Bits found the identical defect living in modern proof-system implementations of Girault's scheme, Bulletproofs, and PlonK, and gave the class a name [@tob_fh].

"We've dubbed this class of vulnerabilities Frozen Heart. The word frozen is an acronym for FoRging Of ZEro kNowledge proofs." -- Trail of Bits, coordinated disclosure, April 2022 [@tob_fh]

The disclosure carried the identifier CVE-2022-29566, describing a flawed Fiat-Shamir implementation that does not include all public values in the challenge [@cve22]. The next year, Quang Dao, Jim Miller, Opal Wright, and Paul Grubbs turned the disclosure into a measured corpus: their peer-reviewed study found 36 weak-Fiat-Shamir instances across 12 different proof systems, with concrete knowledge-soundness attacks on Bulletproofs, PlonK, Spartan, and a verifiable-delay function -- including a case that enabled unlimited currency creation in a vulnerable protocol [@dao23].

The 2022 disclosure reached implementations across many libraries -- iden3's snarkjs, ConsenSys's gnark, Dusk Network's PLonK library, and ZenGo's zk-paillier among them -- all remediated before publication [@tob_fh].

Now the sentence that carries the thesis. Bulletproofs has no trusted setup -- it is transparent, drawing all its randomness from public coins [@stanford_bp]. And it was still a Frozen Heart victim: Trail of Bits traced the bug to an insecure Fiat-Shamir recommendation in the original Bulletproofs paper itself, which the authors then corrected [@tob_fh][@bulletproofs]. Removing the trapdoor did nothing to protect the transcript, because the two are different seams. The hash was perfectly collision-resistant the entire time. The bug was never in the hash -- it was in what entered it.

Three layers, three breaks, one striking regularity: not once did the discrete-logarithm, pairing, or hash assumption itself fail. That regularity is not a coincidence. It is a lens.

5. Name the Layer, Name the Break

Step back from the three incidents and look at the shape they make together. Each one attacked a different part of the artifact -- the circuit, the setup string, the transcript -- and each one lived on the soundness axis. In not one of them did the hardness floor carry the failure. That is not three unrelated stories. It is one lens.

Key idea: Name the layer -- circuit, setup string, or transcript -- and you have named the break. Across the documented incident record, the hardness floor never carries the failure; the leak is always in the artifact humans compiled on top of it.

The lens works because the seams are orthogonal. They live in different parts of the artifact, so closing one does nothing to the others. This is the second aha moment, and it corrects a comfortable intuition. It is tempting to believe that transparent, no-trusted-setup systems are fundamentally safer -- remove the trapdoor and you remove the risk.

But Bulletproofs had no trusted setup and was still forgeable through weak Fiat-Shamir [@tob_fh][@stanford_bp]. Removing the setup seam left the transform seam exactly where it was, because the two are independent coordinates. "Name the layer" fully determines "name the break" only because the layers do not bleed into one another.

flowchart TD A[A verifying proof of a false statement] --> B{"Which layer leaked?"} B -->|Circuit| C[Under-constrained: a missing constraint] B -->|Setup string| D[Trapdoor retained, or a redundant CRS] B -->|Transcript| E[Weak Fiat-Shamir, the Frozen Heart] B -->|Hardness floor| F[Never observed in the record]

Laid out as a table, the whole incident record fits on a single grid.

Seam	Layer	Mechanism	Canonical incident	Caught by
Under-constrained circuit	Arithmetization	Missing constraint admits multiple witnesses	Rollup and mixer withdrawal bugs [@sok24]	Picus, ZKAP, Circomspect
Toxic-waste retention	Setup string	Retained trapdoor forges any statement	Groth16 setup, mitigated by ceremony [@groth16]	MPC ceremony, transparency
Redundant reference string	Setup string	Malformed string lets a statement be swapped	Zcash BCTV14 [@cve19]	Minimal SRS, audit
Frozen Heart	Transform	Weak Fiat-Shamir omits the statement	Girault, Bulletproofs, PlonK [@cve22]	Strong-Fiat-Shamir transcripts

The middle two rows are both the setup seam, split into its two distinct modes. Read down the "Caught by" column and you can already see the shape of the defense: one family of tools per layer, which is exactly how the state of the art is organized.

Complete the picture along the other axis. Nearly every entry in the disclosed corpus is a soundness break, and each maps to exactly one layer of the artifact [@sok24]. The diagonal that matters -- soundness, in the artifact, never the floor -- is the article's thesis rendered as a coordinate grid.

The seams are orthogonal: closing one does nothing to the others.

One honest caveat keeps this from becoming triumphalism. The claim is empirical, not a theorem: the hardness floor has held in every documented incident, which means unbroken so far, not unbreakable. There is exactly one place where the floor itself is on the clock -- a large quantum computer running Shor's algorithm against the discrete-logarithm and pairing assumptions -- and we will give that its due in Section 8. For now, the record is unambiguous: the seams leaked; the floor did not.

If every break has a home layer, then every defense has a target layer too. So how far has the field gotten at sewing each seam shut?

6. Sewing the Seams Shut

There is no single "secure zero-knowledge" method, and looking for one misreads the problem. What exists instead is a defense-in-depth stack with one family of tools per seam -- a structure that mirrors the failure taxonomy exactly, because the defenses were built in response to it [@sok24].

The arithmetization seam gets the most-developed tooling, because it is the most-exploited layer, and the tools sit on a spectrum that trades soundness against scale.

At the sound end is Picus, which implements the QED2 algorithm. It formalizes the exact property a missing constraint violates -- that every output signal must be uniquely determined by the inputs -- and then asks a solver the dual question directly: does a second satisfying assignment exist with the same inputs but different outputs? [@picus23] If the solver proves none can, the circuit is deterministic; if it finds one, it returns a concrete pair of witnesses that demonstrates the bug [@picus_gh].

The catch is that deciding uniqueness over nonlinear field constraints has no efficient general algorithm, so Picus is sound but incomplete: a clean verdict is trustworthy, but it can time out rather than decide. On a benchmark of 163 Circom circuits it resolved roughly 70 percent [@picus23].

At the scalable end is ZKAP, which builds a Circuit Dependence Graph and expresses nine vulnerability anti-patterns as queries over it [@zkap24]. It is a bug-finder, not a prover, so it can miss bug shapes nobody encoded -- but it scans large codebases cheaply, and in evaluation it found 81 real vulnerabilities across 258 Circom circuits, several previously unknown and later fixed by developers [@zkap24]. Fastest of all is Circomspect, the Trail of Bits linter that flags the <-- versus <== slip and other unconstrained-signal patterns at authoring time [@circomspect_gh][@circomspect_blog].

Tool	Approach	Guarantee	Scaling	Output
Picus / QED2	SMT proof of output uniqueness	Sound, incomplete	Weakest (solver cost)	Determinism proof or exploit witness pair
ZKAP	Anti-pattern queries over a dependence graph	Bug-finder; not sound	Strong	Ranked vulnerability findings
Circomspect	Multi-pass linter	Heuristic warnings	Strongest (near-linear)	Warnings (stdout or SARIF)

Note: Run Circomspect in CI to catch the <-- and <== slips as they are written, ZKAP for corpus-scale triage, and reserve Picus to prove your critical circuits deterministic. No single tool is both sound and scalable, so the practical answer is to stack them.

The setup seam offers a three-way choice rather than a single fix: reduce the trust, amortize it, or remove it. Reduce it with an MPC ceremony, whose modern exemplar is Ethereum's KZG Summoning Ceremony -- 141,416 contributions over 208 days, secure if any one contributor was honest [@eth_kzg_blog][@eth_ceremony]. Amortize it with a universal, updatable reference string as in PlonK, where one ceremony serves every circuit up to a size bound and new contributors can inject entropy at any time [@plonk]. Or remove the trapdoor outright with a transparent construction.

A setup that draws only on public randomness -- public coins -- that anyone can reproduce and verify. There is no secret to retain, so there is no trapdoor to leak. By the Goldreich-Oren result it is still a setup; it is simply not a *trusted* one.

Bulletproofs and STARKs are the transparent options: no toxic waste, no ceremony, and no BCTV14-style reference string to get wrong [@bulletproofs][@stark18]. That closes the setup seam completely, at the cost of larger proofs or heavier verification, and -- as we keep seeing -- it does nothing at all for the transform seam.

The transform seam is closed by refusing to hand-roll transcripts. Strong-Fiat-Shamir libraries make weak Fiat-Shamir the non-default.

Merlin, built on the STROBE framework, folds every value into a running transcript through a labeled append_message call and derives challenges from it, so forgetting to bind a public input becomes a visible omission in the code rather than a silent default [@merlin_gh][@merlin_site].

Used correctly, a strong-transcript library eliminates the entire avoidable Frozen Heart class -- every instance that came from an engineer omitting a value from the hash [@merlin_gh]. The honesty this section owes the reader is in the word "avoidable." No tool here is both sound and scalable; a transcript library can still be misused; a hand-rolled challenge gets no protection at all; and, as Section 8 will show, there is a theoretical ceiling above even a perfectly bound transcript. The defenses shrink the attack surface layer by layer. They do not abolish it.

These defenses all assume you have already chosen a proof system. But that choice is upstream of everything here -- it decides which seams you inherit before you write a line of circuit. SNARK or STARK: what does each buy, and what does each still owe?

7. SNARK or STARK: Which Seams You Inherit

The usual comparison of proof systems asks which is fastest or smallest. The thesis reframes the question: which seam does each construction avoid, and which does it inherit? Read that way, the four most-deployed families tell a single clean story.

Groth16's proof is small enough -- around 128 to 192 bytes -- to post on-chain cheaply [@groth16], which is why it stays attractive despite needing a fresh ceremony per circuit.

Groth16 is the smallest and fastest to verify: three group elements, a constant-time pairing check [@groth16]. It inherits the setup seam in its purest form -- per-circuit toxic waste -- and it inherits the transform seam like everything else.

PlonK keeps the succinct proof but relocates the setup seam: one universal, updatable reference string for all circuits instead of one per circuit [@plonk]. It relocates the trapdoor; it does not remove it, and it was itself a Frozen Heart victim [@tob_fh]. Bulletproofs goes further and avoids the setup seam entirely by being transparent [@bulletproofs] -- and was also a Frozen Heart victim [@tob_fh]. STARKs avoid the setup seam too, and additionally trade the algebraic hardness assumption for a hash-based one.

A STARK is a scalable, transparent proof system whose security rests only on collision-resistant hashes. It commits to data with Merkle trees and uses FRI -- the Fast Reed-Solomon Interactive Oracle Proof of Proximity -- to test that a committed function is close to a low-degree polynomial. With no algebraic trapdoor it needs no trusted setup, and by dropping discrete-log and pairing assumptions it sheds the structure that Shor's algorithm targets.

Put them on one grid and read the columns, not the rows.

Dimension	Groth16 (2016)	PlonK (2019)	Bulletproofs (2018)	STARK / FRI (2018)
Proof size	3 elements, ~128 to 192 B	~constant, few hundred B	$2\log_2 n + 9$ elements	polylog, tens to hundreds of KB
Verify cost	~3 pairings (constant)	~constant	$O(n)$, batchable	polylog
Setup seam	Inherited (per-circuit toxic waste)	Relocated (universal trapdoor)	Avoided (transparent)	Avoided (transparent)
Transform seam	Inherited	Inherited (Frozen Heart)	Inherited (Frozen Heart)	Inherited
Hardness floor	Pairings (Shor-breakable)	Pairings + KZG (Shor-breakable)	Discrete log (Shor-breakable)	Hashes (plausibly PQ)
Post-quantum	No	No	No	Conjectural

Move left to right along the setup row and the seam closes: inherited, relocated, avoided, avoided [@groth16][@plonk][@bulletproofs][@stark18]. Now read the transform row: inherited, inherited, inherited, inherited -- all the way across, transparent systems included. That one unbroken column is the entire argument in miniature. Closing the trapdoor does nothing for weak Fiat-Shamir, because they are different seams in the same artifact. And the hardness-floor row never once carries the break; the only future risk it names is the Shor entry, ticking for every algebraic system on the left.

Two disciplined caveats keep this table honest.

Note: For STARKs, "post-quantum secure" is a conjecture. Security rests on the conjectured collision resistance of a hash, which no one has proved survives a quantum adversary, and Grover's algorithm forces larger hash parameters to hold the same margin [@stark18]. Write "plausibly post-quantum," never "post-quantum secure" as if it were settled.

The second caveat is about the word "no." Transparent cores are often wrapped for deployment.

Production STARK pipelines frequently wrap a final Groth16 proof around the STARK so the on-chain verifier checks only a tiny constant-size proof, exactly as RISC Zero's zkVM does when it compresses its final succinct STARK receipt into an on-chain Groth16 receipt [@risc0recursion]. That last mile re-introduces a trusted setup at the recursion boundary. So "no trusted setup" is true of the STARK core, not necessarily of the whole pipeline -- a re-introduced surface by construction, not a documented exploited break.

Ariel Gabizon sits on both sides of this story. He analyzed the BCTV14 redundant-reference-string counterfeiting bug that threatened Zcash [@gabizon19], and he co-authored PlonK, one of the constructions that relocated the setup seam [@plonk]. The expert who found a break also built a defense -- this is a field that advances by adversarial pressure, not a morality tale with heroes and villains.

How each of these systems is actually built -- the QAP compilation, the FRI protocol, the polynomial commitments -- is the subject of the companion article "Never Decrypted: Proving You Ran the Computation." Here we only need enough to see where each one leaks.

Transparency, strong transcripts, sound circuits: with enough care, can we close every seam? The theorems say no -- and they say precisely how far "careful" is even allowed to go.

8. What Being Careful Cannot Fix

Some of the failures in this article are not sloppiness. They are pinned by theorems that tell you how careful you are even allowed to be. Four bounds define the ceiling.

Soundness error is never exactly zero. In the interactive-proof model, a cheating prover convinces the verifier of a false statement with some probability, and you can shrink that probability but never eliminate it for a non-trivial statement [@gmr85].

Note: There is no non-trivial proof system with zero soundness error. You drive the error down toward $2^{-k}$ by enlarging the challenge space or repeating rounds, but never to exactly zero [@gmr85]. "Sound" is always shorthand for "sound except with negligible probability."

Setup is necessary. Goldreich and Oren proved that non-trivial non-interactive zero-knowledge in the plain model collapses to BPP [@go94]. Transparency can downgrade a trusted setup to a public-coin one, but "no setup at all" is unreachable. This is the theorem behind the whole "no trusted setup, never no setup" discipline.

Fiat-Shamir is uninstantiable in the standard model. In 2003, Shafi Goldwasser and Yael Tauman Kalai showed there exists a secure interactive protocol whose Fiat-Shamir version is insecure for every concrete hash function [@gk03]. Strong-transcript engineering removes the avoidable weak-Fiat-Shamir failures, but it cannot lift this ceiling: even a perfectly bound transcript rests on the random-oracle heuristic, not a proof.

For two decades that impossibility was a contrived, almost pathological construction. Then it got real.

In 2025, Dmitry Khovratovich, Ron Rothblum, and Lev Soukhanov moved the 2003 impossibility from a toy protocol to a *practical* soundness attack on a real, deployed GKR-based proof system, generating accepting proofs for false statements for every choice of Fiat-Shamir hash function [@khov25]. Quanta Magazine described it as shaking the bedrock assumption -- proving lies no matter which hash is used [@quanta25]. The guardrail matters: this break lives in the Fiat-Shamir *heuristic*, the transform layer, **not** in the hash's collision resistance. The hardness floor still stands; it is the transform that is now provably crackable in a real case.

That is the third aha moment. The intuition it corrects is the belief that disciplined engineering -- strong transcripts, sound circuits, a clean ceremony -- could in principle make a proof system perfectly and provably sound. The theorems say otherwise: soundness error is irreducible, setup is unavoidable, and Fiat-Shamir soundness has no standard-model proof and now a working counterexample on a real system. Yet even here, at the frontier where the news is worst, the break is in the artifact's heuristic layer, not the discrete-log or hash hardness underneath.

There is exactly one place the hardness floor itself is genuinely on the clock, and intellectual honesty requires naming it. A large quantum computer running Shor's algorithm breaks the discrete-logarithm and pairing assumptions that underpin Groth16, PlonK, and Bulletproofs [@stark18]. That is Q-Day: the one scenario in which the floor, not a seam, gives way. STARKs are the field's hedge against it -- they shed the algebraic target for a hash-based one [@stark18] -- but their post-quantum guarantee is a conjecture, not a theorem.

A strengthening of plain soundness: it demands that any prover who produces a verifying proof must actually *know* a witness, formalized by an extractor that can recover that witness from the prover. Many modern SNARK attacks are knowledge-soundness attacks -- the prover convinces the verifier without knowing any valid witness at all.

Grover's algorithm gives a quadratic speedup on brute-force search, which effectively halves a hash function's security margin. Post-quantum parameters must roughly double the hash output size to hold the same level of security -- one reason STARK proofs are large.

Assemble the four bounds and the perfect proof system dissolves as a target. It would be constant-size, transparent, unconditionally post-quantum, and mechanically proven both sound and correctly constrained end to end. Goldreich-Oren forbids the "no setup" part; Goldwasser-Kalai forbids the standard-model soundness proof that non-interactivity would need; and no construction has a theorem of post-quantum security, only a conjecture with Grover eating into the margin.

The reachable ideal is not a single global optimum. It is a stack of local optima -- sound-verified circuits, transparent setup, strong transcripts, post-quantum-posture hashes -- each seam sewn as tight as its own theorem allows.

If the perfect system is provably out of reach, the honest question is not "is it solved?" but "where, exactly, are the seams still open?"

9. Where the Seams Are Still Open

Five frontiers are visibly moving, and each one is a seam not yet fully sewn.

Sound and scalable circuit verification. The dominant bug class deserves a tool that is both sound and fast, and none exists: Picus proves determinism but times out on large circuits, while ZKAP and Circomspect scale but are incomplete [@picus23][@zkap24][@sok24]. Production circuits run to millions or billions of constraints; the tool that could certify determinism at that scale would close the seam attackers use most.

Closing the Fiat-Shamir theory-practice gap. Strong transcripts eliminate the avoidable weak-Fiat-Shamir bugs, but deployed non-interactive soundness still rests on the random-oracle heuristic, and that gap is widening rather than closing -- the class recurred for a decade, then the 2025 result made the theoretical impossibility a working attack on a real system [@dao23][@gk03][@khov25]. The open goal is a standardized, machine-checkable transcript specification that provably rules out weak instances, or correlation-intractable hashes that instantiate Fiat-Shamir soundly for a practically useful class of protocols.

Trust-minimized setup at Groth16's profile. Transparent systems remove the trapdoor but pay in proof size, verification cost, or a merely conjectural post-quantum guarantee. No construction today matches Groth16's roughly 128-byte, constant-verify profile and transparency and proven post-quantum security at once [@plonk][@stark18][@eth_kzg_blog]. Goldreich-Oren forbids "no setup," so the reachable target is "no trusted setup" -- and the race is to close the size-and-speed penalty.

Provably, not conjecturally, post-quantum arguments. Every deployed pairing or discrete-log SNARK is on Shor's clock, and the hash-based hedge trades that for a conjecture with Grover eating the margin [@stark18]. A succinct argument with an unconditional post-quantum soundness theorem -- not an assumption about a hash -- does not yet exist.

Audit tooling that keeps pace with new arithmetizations. The deepest tooling targets Circom and R1CS, but constructive innovation is racing ahead into AIR, Plonkish custom gates, and full zkVM instruction traces -- re-opening the same arithmetization and transform seams in new syntaxes, including the GKR-inside-a-zkVM setting where the 2025 Fiat-Shamir break actually landed [@sok24][@khov25]. Porting sound analysis to those targets is early-stage work.

Note: The gap between "we linted it" and "we proved it deterministic" is not a footnote -- it is the everyday condition of zero-knowledge auditing. Sound tools do not scale; scalable tools are not sound. Every production audit lives in that gap and closes it with human judgment.

Until these frontiers close, the most reliable defense is not a tool at all. It is a disciplined human review -- one that walks the same three layers, in the same order the bugs appear.

10. A Layer-by-Layer Design Review

Everything in this article compresses into a checklist a reviewer can apply cold: three layers, three questions, asked in the order the bugs actually appear.

Layer 1, arithmetization. Is every signal constrained, with no stray <-- where a <== was intended? Are the outputs uniquely determined by the inputs on the critical path -- provably, not by inspection? Are there aliasing gaps or non-deterministic "hint" signals trusted without an in-circuit check? Run Circomspect in CI to catch the assignment-versus-constraint slips [@circomspect_gh], ZKAP for corpus-scale triage [@zkap24], and Picus to prove determinism on the circuits that guard funds [@picus23]. The property Picus checks is the one you can test yourself in miniature.

{` // Echoes the question Picus/QED2 asks: for fixed inputs, is the output unique? const p = 13; const mod = (a) => ((a % p) + p) % p;

// The author intends "out = 1 exactly when inp is nonzero", but writes only: // inp * out === inp // which forgets to force out to be boolean. Watch input 0 go wrong. function constraintHolds(inp, out) { return mod(inp * out) === mod(inp); }

function acceptedOutputs(inp) { const outs = []; for (let out = 0; out < p; out++) { if (constraintHolds(inp, out)) outs.push(out); } return outs; }

for (let inp = 0; inp <= 2; inp++) { console.log("input", inp, "-> accepted outputs", acceptedOutputs(inp)); } // input 0 accepts EVERY output 0..12 -- under-determined and forgeable. // inputs 1 and 2 accept exactly one output -- uniquely determined. // A determinism checker flags input 0; a plain linter never would. `}

Layer 2, setup. Is the system trusted or transparent? If trusted, was the ceremony run with at least one credibly honest party, and is your reference string byte-identical to the audited transcript you think you are using? [@eth_kzg_blog] Remember that a universal SRS is not the same as no trapdoor -- PlonK's string is reusable, not trustless [@plonk]. Prefer transparency where your proof-size and verification budget allows it; otherwise, verify the ceremony rather than assuming it.

Layer 3, transform. Does the challenge hash bind the domain separator, the statement, all public inputs, and the full transcript? Use an audited transcript library such as Merlin rather than a hand-rolled hash of the commitment [@merlin_gh]. This is the single question that would have prevented every Frozen Heart instance.

Note: 1. Circuit: Is every signal constrained, and is every output uniquely determined by the inputs? 2. Setup: Trusted or transparent -- and if trusted, is your string the audited one and the ceremony credibly honest? 3. Transcript: Does the challenge hash bind the statement and every public input? Three questions, one per seam, in the order bugs appear.

There is a fourth question that sits above the other three: should this be a zero-knowledge system at all?

Key idea: Zero-knowledge adds three failure layers -- circuit, setup, transcript -- above a hardness floor that, on its own, was never the problem. If you need neither privacy nor succinct verification of an untrusted computation, a signature or a re-execution has none of those seams to get wrong. Adopt zero-knowledge only when its guarantees are the ones you actually need.

That is not an argument against zero-knowledge proofs. They do something nothing else can -- verify a computation you never watched, while learning nothing about its secrets. It is an argument for adopting them with open eyes, knowing that each of their conveniences is also a seam.

The checklist works for one reason: every question maps to a layer, and every layer, we now know, is where the breaks actually live. That is the thesis restated as an operating procedure.

11. Frequently Asked Questions

Not by itself. Soundness is defined relative to the *circuit's* constraints, not your intentions. If the circuit is under-constrained, it will certify witnesses the specification never meant to allow, and the verifier accepts them as valid [@sok24]. "Valid" means "some witness satisfied the constraints," which equals "true" only when the constraints were written to force it. No. The setup trapdoor governs *soundness*, not privacy. Whoever retains it can forge proofs of false statements [@groth16], but it tells them nothing about what any honest proof was hiding. Confusing the two misplaces the risk: the trapdoor is a forgery risk, not a de-anonymization one. Conjecturally, not provably. STARK security rests on the conjectured collision resistance of a hash, which no one has proved survives a quantum adversary, and Grover's algorithm forces larger hash parameters to keep the same margin [@stark18]. The correct phrase is "plausibly post-quantum," never "post-quantum secure" as if it were a theorem. Almost never. In the documented record, the break is in the layer above the hardness assumption -- the circuit, the setup string, or the transcript -- while discrete logarithm, pairings, and hashes held [@sok24]. Name the layer and you have named the break; the floor rarely enters the story. No, and that distinction is the point. Timing attacks, faulty randomness, and nonce leakage are real, but they are implementation faults -- the subject of the sibling article "How Zero-Knowledge Broke in Real Life." Everything here is *structural*: it would still be a bug on perfect hardware with a perfect random-number generator. Because the transform seam is orthogonal to the setup seam. Bulletproofs is transparent, yet it was still a Frozen Heart victim through weak Fiat-Shamir, traced to an insecure recommendation in the original paper [@tob_fh][@bulletproofs]. Removing the trapdoor does nothing about what enters the challenge hash. Not yet. No deployed tool is both sound and scalable: Picus proves determinism but times out on large circuits, while ZKAP and Circomspect scale but are incomplete [@picus23][@zkap24]. Production audits close that gap with human review, not tooling alone.

12. Making "Verified" Mean What You Think

Return one last time to the verifier that returned true. Nothing about that bit was wrong. The pairing balanced, the hash matched, and the assumption underneath held -- as it has held in every documented break in this article. What failed was the artifact humans compiled on top of that floor: a circuit missing a constraint, a setup string built or handled wrong, a transcript that hashed too little.

That is the whole argument, and the evidence now sits behind it. Across the disclosed record, the hardness floor never carried the failure [@sok24]. The three seams above it did -- and each break announced its own layer. Under-constrained circuits forge in the arithmetization; retained or malformed setup strings forge in the setup; weak Fiat-Shamir forges in the transform.

Even a transparent, hash-based STARK only sheds the setup seam while inheriting the rest, and its post-quantum promise is a conjecture with Grover's clock running. The one place the floor itself is genuinely at risk is Q-Day, when Shor's algorithm reaches the algebraic assumptions -- the single scenario this article cannot file under "the layer humans built."

The cryptography was never the weak point. The discipline is making sure that when the verifier says "true," it means the thing you actually intended -- constraint by constraint, string by string, hash input by hash input.

Name the layer, and you have named the break. For how these systems are constructed in the first place, see "Never Decrypted: Proving You Ran the Computation." For the implementation and side-channel failures deliberately held out of scope here, see "How Zero-Knowledge Broke in Real Life." Both are the other half of learning to trust a proof you did not watch being made.

The Anonymity That Actually Holds: What Zcash and Monero Prove, and How Each Proof Breaks

noreply@paragmali.com (Parag Mali) — Sun, 19 Jul 2026 00:00:00 GMT

On a public ledger, anonymity is not asserted -- it is *proved*, and every proof carries the break condition of the assumption it rests on. Zcash proves a spend is valid and hidden in the shielded set; its break is an *unsound* proof (the 2018 BCTV14 flaw that would have allowed undetectable counterfeiting) or a set too small to hide in. Monero makes the real spend *statistically* ambiguous among decoys; its break is anything that makes that spend guessable, as the zero-mixin cascades and "guess the newest" heuristic did to early Monero. Name the proof, and you have named the break -- and by 2026 the sharpest break is legal, not cryptographic.

1. Two Coins, Two Hidden Break Conditions

For roughly the first two years of Zcash's life, a flaw buried in its zero-knowledge proof meant that someone holding the right secret could have minted counterfeit shielded coins out of nothing, and no node, auditor, or observer could ever have caught them at it [@ecc-postmortem]. In those same years, a team of academics sat down with the Monero blockchain -- a ledger marketed as untraceable -- and correctly guessed the real coin behind roughly four out of five "hidden" spends [@moser-popets2018]. Both coins were sold as anonymous. Each shipped with a break condition sealed inside its own proof.

That pairing is no coincidence; it is the whole argument of this article. Zcash and Monero are the two most serious answers to one hard question: how do you move value on a public ledger so sender, recipient, and amount stay hidden while everyone can still verify it? They answered in opposite ways. Zcash writes a mathematical proof that a valid, authorized, balanced spend is hidden somewhere in a set. Monero makes the real spend one of many plausible candidates and proves nothing about which is real. They are not merely different mechanisms but different break conditions, chosen at design time.

Key idea: Anonymity on a public ledger is not asserted; it is proved, and a proof is only as strong as the one assumption whose failure is its break condition. Zcash proves a spend is valid and hidden, so its break is a flaw in the proof system (soundness) or in the crowd the proof ranges over (the shielded set). Monero writes a statistical proof that the spend is one of N, so its break is anything that makes N collapse -- a guessable real spend. Name the proof, and you have named the break.

The distinction that organizes everything below is hidden versus provably hidden. A magician's coin is hidden: you cannot see it, but nothing stops you reasoning about where it went. A provably hidden coin comes with a guarantee -- a statement of exactly what an adversary cannot learn, under exactly which assumption. The value of the guarantee is the value of that assumption. When the assumption is "this proof system is sound," the break is a soundness bug. When it is "the real spend is indistinguishable from its decoys," the break is a statistical tell.

Note: Every privacy claim in this article resolves to one question: what, precisely, is being proved, and what happens when the single assumption behind that proof fails? "My transactions are hidden" is marketing. "This spend is one of sixteen, and here is the exact way that set can be narrowed" is engineering. The rest of the article is about turning the first sentence into the second, for both coins.

So this is not a chronology or a feature comparison. It is one claim, argued twice: the anonymity that holds is the anonymity you can prove, and each proof hands you its own break condition for free. The path runs from two 2013 designs that forked at the root, through each coin's construction and documented failure, to the moment the two failures turn out to be the same shape -- and then to a 2026 break no proof, however perfect, can touch. First, though, we need one precise definition of what on-chain anonymity has to prove.

2. What On-Chain Anonymity Actually Has to Prove

Start with what everyone half-knows: a Bitcoin address is not a name, but it is not anonymous either. Because the ledger is public and permanent, every payment an address ever makes or receives is visible forever, and addresses can be linked to each other and, often, to a person. That is pseudonymity, not anonymity.

The gap between the two -- the taxonomy of pseudonymity, unlinkability, and untraceability -- is the subject of the companion post "Pseudonymous Was Never Anonymous," which this article assumes rather than repeats, along with how Bitcoin's base layer gets deanonymized in practice. Here we pick up where it leaves off: given that a transparent pseudonymous ledger is not enough, what would a genuinely private payment have to accomplish?

The answer is more demanding than "hide who I am," because a payment system also has to stay honest. On a public ledger, anyone can verify the rules: no coins are created from nothing, no coin is spent twice, and only the owner can spend. A privacy design cannot quietly drop those checks. It has to hide the transaction and keep proving it valid at the same time.

Note: Every private on-chain payment must do four things simultaneously: hide the sender, hide the recipient, hide the amount, and still prove the transaction is valid (balanced, authorized, and not a double-spend). Drop any of the first three and you have leaked privacy; drop the fourth and you have built a counterfeiting machine. The entire difficulty is doing all four together, in public, with no trusted referee.

Both coins inherit Bitcoin's basic accounting shape. Money exists as discrete outputs; a transaction consumes some existing outputs as inputs and creates new outputs, and the network must confirm that the inputs were real, unspent, and authorized, and that value in equals value out. Transparency makes those checks trivial, because everything is in the clear. Privacy makes them hard, because now the checks have to pass over data nobody is allowed to see. That tension -- verify what you cannot look at -- is the technical heart of the field.

The anonymity set is the collection of possibilities an adversary cannot distinguish among after doing their best analysis. If your spend is genuinely indistinguishable from any of $N$ candidates, your anonymity set has size $N$ and the adversary's best guess is correct with probability $1/N$. The *nominal* anonymity set is the size the design advertises; the *effective* anonymity set is what survives an adversary's heuristics. Almost every result in this article is a gap between those two numbers.

There are only two known ways to make those four requirements hold at once without a trusted referee, and they define the two halves of this article. The first is to attach a cryptographic proof: hide the spend behind commitments, then publish a zero-knowledge argument that a valid spend exists in a committed set, revealing nothing else. The second is to manufacture ambiguity: present the real spend alongside decoys so that, to any observer, it is merely one of many, and design the rest of the transaction so validity still checks out. Zcash took the first road, Monero the second.

The pseudonymity-versus-anonymity taxonomy, and the specifics of Bitcoin base-layer deanonymization, belong to the companion post and are deliberately out of scope here. This piece is about the two constructions that sit above that boundary, and about the precise adversary each one faces -- which is also why the recurring question below is never just "is it private?" but "private against whom, within which set?" That framing comes from the corpus's threat-model post, "Secure Against Whom."

One more thing follows from the definition of an anonymity set: a privacy claim is meaningless until you name the adversary. "Anonymous" against a casual block-explorer user is a different property than "anonymous" against a well-funded chain-analysis firm with heuristics, timing data, and network telemetry. Keep that question -- anonymous against whom? -- in view; it is the question that will still be standing at the end, after every proof has been named and every break condition counted. Two designs answered all of this in 2013, months apart, and they disagreed from the first line about what "hidden" should mean.

3. Two Bloodlines That Forked in 2013

Both design philosophies were born in the same year, months apart, as two answers to the same frustration. By 2013 the state of the art in on-chain privacy was mixing: hand your coins to a tumbler that shuffles them with other people's, or coordinate a joint transaction (CoinJoin) so the graph shows only "one of $k$ paid one of $k$." Mixing works operationally but proves nothing.

A tumbler can steal your coins or keep logs that unwind every link; and CoinJoin, as the Zerocash authors noted, "can thus only mix small volumes of coins amongst users who are currently online, is prone to denial-of-service attacks, and requires effort to find mixing partners" [@zerocash-sp2014]. Both 2013 lineages set out to remove the trusted third party and the online coordination -- and split immediately on how.

A ring signature lets someone sign a message on behalf of a *set* (a "ring") of public keys, so that any verifier is convinced that *some* member of the ring signed, but cannot tell *which one*. Unlike a group signature, there is no manager and no way to later revoke the anonymity. The ring is assembled ad hoc by the signer, who is the only real member; the rest are decoys pulled from the ledger.

The ambiguity lineage came first in spirit. The CryptoNote v2.0 whitepaper, published in 2013 under the pseudonym Nicolas van Saberhagen, defined untraceability through ring signatures (a spend is signed by one of $N$ possible keys) and unlinkability through one-time addresses (each payment lands at a freshly derived key) [@cryptonote-v2]. In April 2014 a community launched Monero as a durable, no-premine deployment of that design [@monero-upgrades]. Nothing here is proved about which output was really spent; the security comes entirely from the spend being lost in a crowd the spender assembles.

CryptoNote's own history is murky: the v2.0 whitepaper is dated 17 October 2013, but a v1.0 carries a December 2012 date and researchers have questioned whether the timestamps were backdated. "Nicolas van Saberhagen" is a pseudonym whose identity has never been established. This article treats "2013 (CryptoNote v2.0)" as the design of record and does not attribute the work to any named person [@cryptonote-v2].

The proof lineage started the same year with the opposite instinct. Zerocoin (Miers, Garman, Green, and Rubin, 2013 IEEE Symposium on Security and Privacy) asked whether anonymity could be proved rather than merely obscured: mint a coin by publishing a commitment that joins a public accumulator of minted coins, then spend it by proving in zero knowledge that you know the opening of some commitment in it, plus a serial number to stop double-spends [@zerocoin-sp2013]. The idea was correct and the proofs enormous -- more than 45 kB each and around 450 ms to verify, far too heavy to be a currency at scale [@zerocash-sp2014].

That cost set up the successor. Zerocash (Ben-Sasson, Chiesa, Garman, Green, Miers, Tromer, and Virza, 2014 IEEE Symposium) replaced the heavy accumulator proof with a succinct one -- a zk-SNARK over note commitments and nullifiers that hides sender, recipient, and amount while proving the transaction balanced and authorized [@zerocash-sp2014]. That construction became Zcash.

A zk-SNARK is a Zero-Knowledge Succinct Non-interactive ARgument of Knowledge. "Zero-knowledge" means the proof reveals nothing beyond the truth of the statement; "succinct" means the proof is small and fast to check regardless of how complex the statement is; "non-interactive" means it is a single message with no back-and-forth; and "argument of knowledge" means a computationally bounded prover cannot produce a convincing proof unless the statement is true and they actually know a witness for it.

A second footnote to Zerocoin's story matters more than the proof size, because it foreshadows the whole article. Zerocoin carried a break with nothing to do with the soundness of its zero-knowledge proof. Ruffing, Thyagarajan, Ronge, and Schroeder showed in 2018, in a paper aptly titled "Burning Zerocoins," that a network attacker could permanently destroy honest users' coins -- a "cryptographic denial-of-spending attack" that, in the authors' words, "does not contradict the formal security analyses" of the original scheme, because it exploited a property nobody had modeled [@ruffing-burning-zerocoins].

Hold onto that shape: a construction can be proved, in the exact sense its authors intended, and still break at the edge of what the proof was ever about. "Proved" and "unbreakable" are different words, and the distance between them is where most of this article lives.

There is one more seam worth flagging now, because it detonates in Section 5. Zerocash's succinct proof rode on the pairing-based zk-SNARK template introduced by Pinocchio (Parno, Howell, Gentry, and Raykova, 2013), and the concrete construction Zcash shipped -- known as BCTV14, after Ben-Sasson, Chiesa, Tromer, and Virza -- inherited its security argument from that lineage rather than carrying a dedicated proof of its own [@pinocchio-pghr13] [@bctv14]. Hold that thought too.

flowchart TD Root["2013: a public ledger is transparent and pseudonyms are linkable"] Root --> Proof["Proof school: hide the spend, prove it is valid anyway"] Root --> Amb["Ambiguity school: make the real spend one of N candidates"] Proof --> P1["Zerocoin 2013 (accumulator + zero-knowledge membership)"] P1 --> P2["Zcash Sprout 2016 (BCTV14 zk-SNARK)"] P2 --> P3["Zcash Sapling 2018 (Groth16)"] P3 --> P4["Zcash Orchard 2022 (Halo 2, no trusted setup)"] Amb --> A1["CryptoNote 2013, Monero 2014 (ring signatures + stealth addresses)"] A1 --> A2["RingCT 2017 (amounts hidden)"] A2 --> A3["Mandatory RingCT 2017; ring 11 + Bulletproofs 2018"] A3 --> A4["CLSAG 2020; ring 16 + Bulletproofs+ 2022"] P4 --> Law["AMLR Article 79 legal ban, effective 10 July 2027"] A4 --> Law

Here is the thesis in historical form: the split in proof strategy is the split in break condition, present at birth. Choose to hide by proof, and you inherit two ways to fail -- an unsound proof, or a set too small to hide in. Choose to hide by ambiguity, and you inherit exactly one -- a real spend that becomes guessable. Everything that follows is those two inheritances playing out. The proof school promised something that sounds impossible, so we start there: how do you prove a spend is valid without revealing which spend it is?

4. The Zcash Construction: Proving a Spend You Cannot See

Zcash's shielded pool is best understood as a machine for making one specific statement believable without evidence you can inspect. To spend, you must convince every node that a real, unspent coin you own is being consumed and that value balances -- while showing them none of: which coin, whose coin, or how much. It pulls this off with three moving parts and a proof that ties them together.

The first part is the note. A shielded coin is a note -- a bundle of (value, owner key, randomness) -- that never appears on chain in the clear. What appears is its commitment.

A note commitment is a cryptographic commitment to the contents of a note (its value, the owner's key, and a random nonce). Like a sealed envelope, it *binds* the sender to those exact contents (they cannot change them later) while *hiding* them from everyone. Every new note's commitment is appended to a global, append-only Merkle tree, so "this note exists" becomes "this commitment is a leaf in the tree."

The second part solves double-spending without identity. In a transparent chain you stop double-spends by pointing at the specific coin being consumed; here you are not allowed to point at anything. The answer is the nullifier.

A nullifier is a deterministic tag derived from a note's secret data such that each note maps to exactly one nullifier, but the nullifier reveals nothing about which note produced it. Spending publishes the nullifier; the network records it in a set and rejects any future transaction that reuses it. This voids the note -- provably, and exactly once -- without ever disclosing which leaf of the commitment tree was spent.

The third part is the zk-SNARK that ties it together. A shielded spend carries a succinct zero-knowledge proof of the following statement: I know an opening of a note whose commitment is a leaf in the tree; its nullifier is correctly derived; I am authorized to spend it; and the input value equals the output value [@zerocash-sp2014] [@zcash-protocol-spec]. A verifier who checks that proof learns only one bit -- the statement is true -- and nothing about the note, the owner, or the amount.

flowchart TD Note["A note commitment sits in the append-only tree (value + owner key + randomness)"] Auth["Spender demonstrates spend authorization"] Null["Nullifier is published, voiding the note without naming it"] SNARK{"zk-SNARK verifies: membership + authorization + nullifier + balance"} Out["Fresh output note commitments are appended"] Note --> SNARK Auth --> SNARK SNARK --> Null SNARK --> Out

That is the model. Everything else in Zcash's history is a change of proving system underneath the same model -- and each change was forced by a break condition, which is exactly the thesis. The pool has run three proving systems.

The first, Sprout, shipped at the 2016 mainnet launch on the BCTV14 zk-SNARK, encoding a spend proof in 288 bytes [@zcash-begins] [@zcash-protocol-spec].The protocol specification encodes the Sprout proof in 288 bytes and the Sapling Groth16 proof in 192 bytes; the older literature sometimes quotes 296 bytes for Sprout because of a difference in point encoding [@zcash-protocol-spec]. Its parameters came from a multi-party "trusted setup" ceremony -- which introduces the one idea most people get wrong.

A pairing-based zk-SNARK needs public parameters called a structured reference string (SRS), generated from secret randomness. That secret is the "toxic waste": anyone who retains it can forge proofs of false statements. A trusted-setup ceremony has many participants jointly generate the SRS so that the waste is safe as long as *at least one* participant honestly destroys their share. Note carefully what the waste can and cannot do. The single most common misconception about Zcash is that the trusted-setup "toxic waste" is a key that decrypts people's transactions. It is not. The secret governs the proof system's *soundness*, not its *privacy*. A party who kept the waste could counterfeit coins by proving false statements, which is catastrophic for the money supply -- but they could not deanonymize a single shielded transaction, because the hiding comes from the commitments and the zero-knowledge property, not from the SRS. When you read "trusted setup risk," read "counterfeiting risk," never "surveillance backdoor."

The second system, Sapling (October 2018), kept the model but swapped in Jens Groth's 2016 pairing-based zk-SNARK, "Groth16," whose proof is just three group elements -- 192 bytes -- and, unlike BCTV14, carries a rigorous, independently reviewed security analysis [@groth16] [@zcash-protocol-spec] [@ecc-sapling-foundations]. Purpose-built curve and circuit engineering cut the prover's cost by roughly 80% in time and 98% in memory versus Sprout, which is what first made shielding feasible on a phone [@ecc-sapling-faster]. Sapling still needs a per-circuit trusted setup; it fixed the soundness of the proof, not the existence of the ceremony.

The third system, Orchard, activated at Network Upgrade 5 on 31 May 2022 [@zcash-v5-release] and specified in ZIP 224 [@zcash-zip224], removed the ceremony altogether. It is built on Halo 2, whose inner-product argument descends from the 2019 Halo proposal for recursion without a trusted setup [@halo-2019] and, in the Electric Coin Company's words, "did not require a trusted setup and had relatively small proof sizes, at the cost of poor verification performance" [@ecc-halo2]. Orchard runs over the Pallas and Vesta ("Pasta") curves [@zcash-protocol-spec] -- a transparent, no-setup instantiation, not a universal or updatable SNARK.

Proving system (era)	Spend proof size	Trusted setup	Curve	Status
Sprout / BCTV14 (2016)	288 bytes [@zcash-protocol-spec]	Yes, per-circuit	pairing-friendly (BN)	Superseded 2018
Sapling / Groth16 (2018)	192 bytes, three elements [@zcash-protocol-spec]	Yes, per-circuit	BLS12-381 + Jubjub	Active
Orchard / Halo 2 (2022)	Logarithmic in circuit size, no fixed constant [@ecc-halo2]	No	Pallas / Vesta ("Pasta")	Active default

The seam that mattered: BCTV14 shipped without a dedicated security proof and leaned on the Pinocchio/PGHR13 analysis it descended from. Bryan Parno had already found a different error in BCTV14 in 2015, a hint that the construction's proof story was thinner than its deployment suggested [@pinocchio-pghr13] [@parno15]. That gap between "used in production" and "proven sound" is precisely where the 2018 break was hiding.

Read the table against the thesis and the shape is clear: this is a literal mathematical proof, so the guarantee is exactly as strong as the proof's soundness. Sapling and Orchard improved the guarantee by improving the proof -- better analysis, then no ceremony. But that framing carries an unavoidable implication. If your anonymity is a proof, then a false proof is a broken anonymity. This proof shipped in 2016. In 2018, someone discovered it was unsound. What does it even mean for a proof to be false?

5. When the Proof Itself Is Unsound: The BCTV14 Break

On 1 March 2018, Ariel Gabizon, a cryptographer at the Electric Coin Company, was studying the BCTV14 setup and noticed something that should not have been there. The parameter-generation procedure, as described in the paper, "mistakenly produces extra elements that violate the soundness of the proving system" [@ecc-postmortem]. An honest prover ignores those elements and never notices. But their presence, in the postmortem's exact words, "allows a cheating prover to circumvent a consistency check, and thereby transform the proof of one statement into a valid-looking proof of a different statement" [@ecc-postmortem].

"The parameter setup algorithm ... mistakenly produces extra elements that violate the soundness of the proving system." -- Electric Coin Company postmortem [@ecc-postmortem] A proof system is *sound* if no prover can produce a convincing proof of a false statement, except with negligible probability. For succinct *arguments* like zk-SNARKs the guarantee is *computational* soundness: no prover bounded to feasible computation can forge a proof, assuming some hardness problem holds. Soundness is the promise that "verified" means "true." Break it, and a verified proof means nothing.

What were those extra elements, concretely? This is the part summaries skip, and the mechanism is the whole lesson. Gabizon's own write-up (IACR ePrint 2019/119) states it precisely: the flaw "stems from including redundant elements in the CRS," the structured reference string -- elements the Pinocchio/PGHR13 template had deliberately excluded and that are, in his words, "vital not to expose" [@gabizon-2019-119]. Publishing them let a cheating prover do something specific and devastating: "creating a proof of knowledge for any public input given a valid proof for some public input" [@gabizon-2019-119].

In other words, hand the attacker one honestly generated proof, and the redundant CRS elements let them retarget it to a statement of their choosing. The BCTV14 paper's own errata later acknowledged it "fixes an error in Appendix B, found by Ariel Gabizon" [@bctv14]. With the excluded elements kept out, the construction was secure in an idealized generic-group model -- but the deployed parameters kept them in [@gabizon-2019-119].

Read what that retargeting buys an attacker. The shielded pool's whole security rests on the proof meaning "this spend is valid and balanced." If a cheating prover can attach that same certificate to a false statement, they can prove a spend is balanced when it is not -- creating shielded value from nothing. This is not a privacy bug; it is a counterfeiting bug, and it would have been invisible.

Note: Forged value minted inside the shielded pool is cryptographically undetectable: every proof still verifies, so no node, auditor, or user can distinguish an honest shielded balance from an inflated one. The only instrument that could ever register an anomaly is the "turnstile" that meters net value crossing the boundary between the transparent and shielded pools in aggregate -- and it measures totals, not individuals. Zcash's turnstile never showed such an anomaly, and there is no evidence the flaw was exploited [@ecc-postmortem]. "Undetectable" here is a statement about the mathematics, not a guess about attacker behavior.

The proof was real mathematics, and it was false. The human story around that sentence is small and tense. Gabizon confirmed the flaw with his colleague Sean Bowe, and the two briefed chief executive Zooko Wilcox and engineer Nathan Wilcox. For a time just four people knew that the currency they were building could, in principle, be counterfeited without a trace [@ecc-postmortem].

The exploit required data that survived only in the original Sprout multi-party ceremony transcript -- the extra elements are present there even though the shipped parameter files omit them -- so the company quietly removed the transcript, maintaining a cover story that it had been lost to accidental deletion [@ecc-postmortem].

The fix was not a patch, because you do not patch an unsound proof. You replace it. Sapling's move to the independently analyzed Groth16 circuit, activated 28 October 2018, migrated shielded value off the flawed system entirely, and only then -- on 5 February 2019, eleven months after discovery -- did the company disclose publicly [@ecc-postmortem].

The postmortem records how far the flaw reached: the same bug had propagated into Fuchsbauer's subversion-zero-knowledge adaptation and the ADSNARK scheme, and the Sprout parameters themselves came from a multi-party protocol (BGG17) that carried the extra elements forward [@fuchsbauer17] [@adsnark-bbfr14] [@bgg17]. Parno's 2015 note had already flagged a separate soundness problem in the same construction [@parno15]. The mathematics was reviewed, published, deployed -- and still wrong for years.

flowchart TD Setup["BCTV14 parameter setup emits redundant CRS elements (unused by honest provers)"] Setup --> Honest["Honest prover ignores the extra elements"] Setup --> Cheat["Cheating prover keeps the extra elements"] Honest --> HCheck{"Consistency check"} HCheck --> Sound["Only true statements pass: valid spends"] Cheat --> Bypass{"Consistency check is circumvented"} Bypass --> Forge["Some-input to any-input: a false statement passes, undetectable in-pool counterfeiting"]

The postmortem says the flaw was responsibly disclosed to two other affected projects but does not name them; secondary press identified them as Horizen and Komodo. Attribute those names to reporting, not to the primary source, which names no one [@ecc-postmortem].

That is one way a proof-based system breaks: the proof is wrong. There is a second, quieter way that survives even a perfect proof. A zero-knowledge proof of membership only hides you inside the set it ranges over -- and for Zcash, that set is whatever value has actually been shielded.

Kappos, Yousaf, Maller, and Meiklejohn measured the deployed pool: only 14.96% of transactions ever interacted with the shielded pool at all, roughly 3.9 million ZEC flowed in and back out in a near-perfect reflection dominated by founders and miners, and a handful of simple usage heuristics cut the effective anonymity set by 69.1% [@kappos-usenix2018]. The proof was sound; the crowd it proved over was thin.

The Kappos measurement is blunt about who was in the pool: about 3,901,124 ZEC were deposited and 3,788,889 withdrawn in a "near-perfect reflection ... accounted for almost fully by the founders and miners," with roughly 76.7% of pool deposits coming from miners [@kappos-usenix2018]. A shielded pool used mostly as a pass-through by two known cohorts is a small crowd to hide in.

So the proof school's break condition has two faces, and we can write the first row of a table we will fill in completely later. What Zcash proves, and how, and the exact assumption whose failure is the break:

System	What is proved	By what mechanism	Break condition	Anonymous against whom / within which set
Zcash Sapling	"This spend is valid, authorized, balanced, and hidden in the shielded set"	Groth16 zk-SNARK over BLS12-381, note commitments and nullifiers	An unsound proof (the BCTV14 precedent) or a trusted-setup leak -- and a thin real set	A chain observer, within the set that actually shielded (small in practice) [@kappos-usenix2018]
Zcash Orchard	The same statement, with no ceremony to trust	Halo 2 inner-product argument (transparent) plus recursion	An unsound argument or discrete-log break; the trusted-setup class is removed, but the set is still thin	A chain observer, within the Orchard set (opt-in) [@ecc-halo2]

The proof school's failure was a discrete event with a date and four names. The other school never had a single break at all. Its anonymity eroded slowly, one measurement at a time -- and to see why, we need Monero's construction.

6. The Monero Construction: Hiding in a Crowd You Assemble Yourself

Monero makes the opposite bet. It proves nothing about which output was spent. Instead it makes the real spend one of many plausible candidates and arranges the rest of the transaction so validity still checks out. Four primitives work in lockstep to hide sender, recipient, and amount while proving the payment is honest.

Sender ambiguity comes from the ring signature. To spend an output, you assemble a ring of that one real output plus a set of decoys pulled from the chain, and produce a signature proving that some ring member authorized the spend, without revealing which [@cryptonote-v2]. A verifier sees a valid signature over a ring of, today, sixteen members, and has no cryptographic handle on which one is real.

That immediately raises a problem: if you never say which output you spent, how does the network stop you from spending it twice? The answer is a linkable ring signature and its key image.

A key image is a deterministic tag derived from the real signing key, published with every Monero spend. It is unique to the key that actually signed, but reveals nothing about which ring member that was. The network keeps a set of seen key images and rejects any transaction that reuses one. This is the exact analogue of Zcash's nullifier: it prevents double-spends by catching reuse, not by naming the coin.

Recipient unlinkability comes from stealth addresses.

A stealth, or one-time, address is a fresh public key that the sender derives for each payment from the recipient's long-term address, using a shared secret only the two of them can compute. Funds land at that one-time key, never at the published address, so two payments to the same person produce two unrelated on-chain destinations that no observer can link.

Amount hiding comes from RingCT (Ring Confidential Transactions), which bolts Pedersen-committed amounts and range proofs onto the ring signature [@ringct-mrl0005] [@confidential-tx].

A Pedersen commitment to a value $v$ with random blinding factor $r$ is $C = vG + rH$, where $G$ and $H$ are fixed group generators with no known relationship. It perfectly hides $v$ (any $C$ is consistent with any value, given the right $r$) and is *additively homomorphic*: $C(v_1, r_1) + C(v_2, r_2) = C(v_1 + v_2,\; r_1 + r_2)$. That homomorphism is what lets a verifier confirm inputs minus outputs equal zero without learning a single amount.

The homomorphism is worth seeing directly, because it is how a public network checks that hidden numbers balance. Commit two amounts with independent blinding factors, and the product (in a multiplicative group) or sum (in the additive elliptic-curve notation Monero actually uses) of the commitments equals the commitment to the summed values -- so "the amounts balance" becomes a single equality on commitments.

{` // Illustrative only: real Monero uses a large elliptic-curve group with additive // notation C = vG + rH. Here we use modular exponentiation in a prime field, where // the same homomorphism reads as a product of commitments. The point is the algebra. const p = 2n ** 61n - 1n; // a Mersenne prime, big enough for the demo const g = 5n, h = 7n; // two public generators with no known relationship

const modpow = (base, exp, m) => { let r = 1n; base %= m; while (exp > 0n) { if (exp & 1n) r = (r * base) % m; base = (base * base) % m; exp >>= 1n; } return r; };

// commit(v, r) = g^v * h^r mod p -- hides v behind the blinding factor r const commit = (v, r) => (modpow(g, v, p) * modpow(h, r, p)) % p;

const v1 = 40n, r1 = 12345n; // amount 1 and its blinding factor const v2 = 25n, r2 = 67890n; // amount 2 and its blinding factor

const C1 = commit(v1, r1); const C2 = commit(v2, r2); const Csum = commit(v1 + v2, r1 + r2);

console.log('C1 . C2 mod p =', (C1 * C2) % p); console.log('commit(v1+v2, r1+r2) =', Csum); console.log('do they match? ', ((C1 * C2) % p) === Csum); // A verifier tests whether input commitments minus output commitments cancel, // confirming value in = value out, while learning neither v1 nor v2. `}

Range proofs finish the job. Without them, you could "balance" a transaction by committing to a negative output, minting value while the equation still holds.

A range proof is a zero-knowledge proof that a committed value lies in a valid range (say, between zero and $2^{64}-1$) without revealing the value. It closes the negative-amount loophole in a confidential-transaction scheme. Monero's first range proofs (Borromean) were large; Bulletproofs replaced them with logarithmic-size proofs that need no trusted setup, and Bulletproofs+ shrank them further.

Monero's Borromean range proofs were large and dominated transaction size. In October 2018 they were replaced by Bulletproofs -- logarithmic-size range proofs with no trusted setup -- which cut the average Monero transaction size by at least 80% [@bulletproofs-sp2018] [@moneropedia-bulletproofs] [@stanford-bulletproofs]. A shorter successor, Bulletproofs+, shipped in August 2022 [@bulletproofs-plus].

flowchart TD Ring["Assemble a ring: 1 real output + 15 decoys from the chain"] Sig["Linkable ring signature proves one member signed, not which"] KI["Key image published, unique to the real key, catches double-spends"] Stealth["Payment lands at a fresh one-time stealth address"] Amt["Amount hidden by a Pedersen commitment + Bulletproof+ range proof"] Ring --> Sig Sig --> KI Sig --> Stealth Stealth --> Amt

The deployment history is a ratchet, and every notch is dated in the project's source of record: RingCT went live as optional in January 2017, became mandatory in September 2017, the ring size was fixed at 11 in October 2018, and raised to 16 in August 2022 [@monero-upgrades]. Alongside those, the signature scheme moved from MLSAG to the smaller, faster CLSAG in October 2020, with the same one-of-N guarantee [@clsag].

That the signature could be swapped so freely -- MLSAG to CLSAG, with no change to the security story -- is itself a tell. A 2024 Cypher Stack review even found two gaps in CLSAG's formal security proof, with, in the project's words, no effect on "the Monero implementation of CLSAG, so users are not at risk" [@clsag]. The break in Monero was never the signature scheme; it was always the decoys. You can optimize or even re-prove the signature all you like and the anonymity is unaffected, because the anonymity lives in the ring, not in the algebra of the signature [@clsag].

Now hold this construction next to Zcash's and the deep difference is exact. Zcash makes a cryptographic proof, so it can have a soundness flaw. Monero makes a statistical proof of ambiguity, so there is no soundness flaw to find -- there is no cryptographic assertion about which output was spent that could be false. The guarantee is instead exactly as strong as the crowd is indistinguishable. Which raises the only question that can break it: what if the decoys do not look like real spends?

7. When the Crowd Collapses: Monero's Statistical Break

Nobody forged a Monero coin. The break was subtler and, for a privacy coin, arguably worse: researchers simply guessed which ring member was real, and were right most of the time. Because the hiding is statistical, the whole guarantee is only as good as the decoys, and early Monero decoys were terrible.

The first lever was the ring of size one. In early Monero many inputs used no decoys, and a ring with one member is not a ring -- the real spend is named outright. Kumar, Fischer, Tople, and Saxena showed in 2017 that these zero-mixin inputs are not just individually traceable; they cascade [@kumar-esorics2017]. Once an output is proven spent, it can be eliminated as a decoy everywhere it later appears. Each elimination can shrink another ring to one candidate, which is itself then proven spent, poisoning the next ring, and so on. One collapse propagates through the graph.

flowchart TD Z["Zero-mixin input, ring size 1: the real spend is named outright"] Z --> P1["That output is now known to be spent"] P1 --> R1["A later ring used it as a decoy, so eliminate it"] R1 --> C1["That ring shrinks and its real input can be forced"] C1 --> R2["The forced output poisons the next ring in turn"] R2 --> C2["The crowd collapses ring by ring, a chain reaction"]

Moser and ten co-authors measured how bad this was and added a second, independent attack [@moser-popets2018]. As of one April 2017 snapshot, 64.04% of all transaction inputs carried no mixins at all, and about 62% of inputs with one or more mixins were deducible by that chain-reaction elimination.

Then the temporal attack. Because early decoys were sampled with no regard for how old real spends tend to be, the real input was almost always the newest member of its ring. The "guess the newest" heuristic was correct about 80% of the time over all transactions with at least one mixin, and still 81% even among transactions meeting the minimum ring size mandated after September 2017 [@moser-popets2018].

"The real input is usually the 'newest' input ... [we can] guess the real input with 80% accuracy over all transactions with 1 or more mixins." -- Moser et al., PoPETs 2018 [@moser-popets2018]

Note: There is no theorem to disprove here and no soundness bug to find. Monero's ambiguity is a claim about a probability distribution: the real spend should be indistinguishable from its decoys. The attacks do not break any math; they exploit the gap between the decoy distribution the software produced and the distribution real spends actually follow. When those two distributions differ, the crowd is only nominally a crowd.

The simulation below shows the mechanism and, just as importantly, the fix. With decoys sampled uniformly from all history, a genuinely recent real spend stands out as the newest ring member almost every time. Sample decoys from the same recency distribution that real spends follow, and the real output stops standing out -- the attacker's success falls back toward the one-in-sixteen a random guess would give.

{` // Toy model of Monero decoy selection. Outputs are created over time; a higher index // means a newer output. Real spends tend to be RECENT. We build a ring of the real // output plus decoys, then apply the attacker's heuristic: guess the newest member. const RING = 16; // ring size (Monero has used 16 since August 2022) const TRIALS = 50000; const POOL = 100000; // number of past outputs available as decoys

function gaussian() { // Box-Muller, standard normal const u = Math.random(), v = Math.random(); return Math.sqrt(-2 * Math.log(u)) * Math.cos(2 * Math.PI * v); } // Real spends skew recent: age is a small offset back from the newest output. const realAge = () => Math.floor(Math.abs(gaussian()) * 1800);

function runSim(pickDecoy) { let correct = 0; for (let t = 0; t < TRIALS; t++) { const realIndex = POOL - 1 - realAge(); // a recent real output const ring = [realIndex]; while (ring.length < RING) ring.push(pickDecoy()); const guess = Math.max(...ring); // heuristic: newest is real if (guess === realIndex) correct++; } return (100 * correct / TRIALS).toFixed(1); }

// 1) Naive UNIFORM decoys (early Monero): spread across all history. const uniform = () => Math.floor(Math.random() * POOL); // 2) REALISTIC decoys: same recency skew as real spends. const realistic = () => POOL - 1 - realAge();

console.log('Uniform decoys -> guess-newest correct:', runSim(uniform), '%'); console.log('Realistic decoys -> guess-newest correct:', runSim(realistic), '%'); console.log('Random baseline -> 1 in 16:', (100 / RING).toFixed(1), '%'); `}

That is why every Monero mitigation reads like a direct answer to the attack that named it, which is the pattern this failure-mode style prizes. Mandatory RingCT (September 2017) meant RingCT outputs could no longer be spent by zero-mixin inputs, structurally ending the cascade at its source. Zero-decoy spends were eliminated. The ring size was fixed at 11, then 16, so no transaction advertises a distinctive ring size and the crowd is uniform. And decoy selection moved to a gamma distribution designed to mimic the real spend-age curve, directly targeting the guess-newest tell [@monero-upgrades] [@moser-popets2018].

Guess-newest works because real spends cluster at a particular age -- recent, but not the newest block, since coins need confirmations and people spend on human timescales. Uniform decoy selection ignores that shape, so the real input's age stands out. A gamma distribution is a two-parameter family tunable to the observed spend-age curve, so a decoy drawn from it looks, age-wise, like a plausible real spend. The mitigation is not "more decoys" but "decoys drawn from the right distribution" -- which is why sixteen realistic decoys beat sixty-four obvious ones, and why decoy realism, not ring size, is the live problem [@moser-popets2018].

Kumar et al. (ESORICS 2017) and Moser et al. (PoPETs 2018) were concurrent and independent; the Moser paper cites the Kumar work as related. Read together they are the canonical measurement of Monero's statistical break, and the reason gamma-distributed decoy selection and larger rings became protocol priorities [@kumar-esorics2017] [@moser-popets2018].

Note the honest epistemics, because they are the whole point. None of this made Monero unconditionally private. It is a ratchet, not a proof: each turn raises the cost of the statistical attack, but the guarantee stays statistical and the crowd stays bounded at sixteen. Decoy realism versus improving classifiers is a permanent arms race.

So the Monero row of our recurring table writes itself: what is proved is one-of-N ambiguity; the mechanism is ring signature plus stealth address plus RingCT; the break is that N collapses when a real spend becomes guessable; and it holds against a chain observer within a ring of sixteen, only as far as the decoys are realistic. Two coins, two breaks -- one a flaw in a proof, the other a collapse of a crowd. Are those different problems, or the same problem wearing two masks?

8. Head-to-Head: Cryptographic Anonymity Versus Statistical Anonymity

Put the two proofs on one table and the symmetry is startling. Here is the recurring device, now filled for both coins and both frontier systems: what each proves, by what mechanism, the single assumption whose failure is its break, and the adversary and set it holds against.

System	What is proved	By what mechanism	Break condition	Anonymous against whom / within which set
Zcash Sapling	This spend is valid, authorized, balanced, and hidden in the shielded set	Groth16 zk-SNARK over BLS12-381, commitments and nullifiers	An unsound proof (the BCTV14 precedent) or a trusted-setup leak; and a thin real set	A chain observer, within the set that actually shielded, small in practice [@kappos-usenix2018]
Zcash Orchard	The same statement, with no ceremony to trust	Halo 2 inner-product argument (transparent) plus recursion	An unsound argument or discrete-log break; the trusted-setup class is removed; the set is still thin [@ecc-halo2]	A chain observer, within the Orchard set (opt-in)
Monero RingCT	The real spend is one of sixteen ring members; amounts balance and are in range	CLSAG linkable ring signature, stealth addresses, RingCT with Bulletproofs+	The N collapses: guessable decoys, chain-reaction near 62% and guess-newest near 80% before mitigation; a bounded ring [@moser-popets2018]	A chain observer, within a ring of sixteen, only as far as decoys are realistic
Monero FCMP++	The real spend is one of every output on the chain	Curve-Trees membership proof, Generalized Bulletproof, Generalized Schnorr	An unsound Generalized Bulletproof or discrete-log break; soundness proofs still being formalized [@fcmp-ccs]	A chain observer, within the entire output set, roughly 100,000,000 [@fcmp-blog]

The engineering trade-offs behind those rows are what a protocol designer actually weighs.

Dimension	Zcash Sapling	Zcash Orchard	Monero RingCT	Monero FCMP++
Anonymity model	Cryptographic proof	Cryptographic proof, transparent	Statistical ambiguity	Cryptographic membership proof
Trusted setup	Yes, per-circuit	No	No	No
Proof / tx size	About 192-byte proof, about 2.8 KB tx [@zcash-protocol-spec] [@curve-trees]	Logarithmic proof, larger than Groth16 [@ecc-halo2]	At least 80% smaller than pre-Bulletproofs [@moneropedia-bulletproofs]	About 2.9 KB proof, about 4 KB tx [@curve-trees]
Verify cost	Constant, cheapest	Heavier, near-constant when batched [@ecc-halo2]	Grows with ring size times inputs	About 80 ms single tx, about 5 ms batched over 100 [@curve-trees]
Anonymity set (nominal)	All shielded notes	All Orchard notes	16 per input [@fcmp-blog]	About 100,000,000 [@fcmp-blog]
Anonymity set (effective)	Far below nominal, founder and miner dominated [@kappos-usenix2018]	Same structural risk, opt-in	16 or fewer, often collapsible [@moser-popets2018]	Equal to nominal, the full chain
Post-quantum	No, pairings	No, discrete log	No, discrete log	Privacy forward-secret against a DL oracle, soundness not PQ [@fcmp-blog]
Default privacy	Opt-in	Opt-in	Always-on	Always-on
Deployed?	Yes (2018)	Yes (2022, default)	Yes (current)	No (audited, in development)

Note: Every nominal anonymity-set number in these tables has a smaller twin. Zcash's pool is nominally every shielded note but effectively a much smaller set once the founder and miner round-trips are removed [@kappos-usenix2018]; Monero's ring is nominally sixteen but was effectively closer to one for early transactions [@moser-popets2018]. The adversary never faces the number on the box. They face the number that survives their heuristics, and closing that gap is the real work.

Now read the four rows against the thesis and the deep structure appears. The two Zcash rows and the FCMP++ row all say the same thing -- a proof is exactly as strong as its soundness and the set it ranges over. The Monero RingCT row is the ambiguity variant -- a crowd is exactly as strong as it is indistinguishable.

And a startling diagonal runs through the table. As Monero moves from RingCT down to FCMP++, it stops being statistical and becomes a proof: the anonymity set jumps from sixteen to the whole chain, but the break changes species, from "a guessable decoy" to "an unsound Generalized Bulletproof." Monero, chasing a bigger crowd, walks straight into the proof school's break condition. Meanwhile Zcash, moving from Sapling to Orchard, keeps the proof but discards the trusted-setup break entirely.

Key idea: The two schools are converging on the same ideal from opposite corners. Monero is adding a proof to escape a collapsible crowd; Zcash is removing a trusted setup to shed a soundness liability. The shared destination is a transparent, sound, full-set membership proof -- and the moment Monero reaches it, it inherits exactly the break condition Zcash spent a decade learning to fear. Name the proof, and you have named the break.

flowchart TD S["Zcash Sapling: a sound proof, but a trusted setup"] O["Zcash Orchard: proof kept, trusted setup removed"] R["Monero RingCT: statistical ambiguity over a ring of 16"] F["Monero FCMP++: a membership proof over the whole chain"] Ideal["Transparent, sound, full-set membership proof"] S --> O O --> Ideal R --> F F --> Ideal

If both roads lead to the same ideal proof, a natural question follows: is there a ceiling neither road can pass? There is, and it is a theorem rather than an engineering wart.

9. The Ceiling and the Floor: What No Construction Can Escape

Suppose the proof is perfect and the trusted setup is gone. Are you finally, unconditionally anonymous? No -- and the reasons are theorems, not engineering warts. Three limits sit under every system in this article, and naming them turns the whole comparison from a horse race into a map.

The first is a ceiling. You cannot be more anonymous than the crowd your proof ranges over. If the set an argument covers has size $k$, then an adversary with no other information already guesses the real spender with probability at least $1/k$, and every usable heuristic only pushes that up. This $k$-anonymity ceiling is why FCMP++ is a genuine theoretical advance rather than an optimization: raising the ring from sixteen to the whole chain does not tune a constant, it raises the ceiling itself, from $k \approx 16$ to $k \approx 10^{8}$ [@fcmp-blog] [@curve-trees].

It is also why the empirical papers matter so much. Moser's and Kappos's results are precisely measurements of the gap between the nominal ceiling and the effective set the adversary actually faces [@moser-popets2018] [@kappos-usenix2018]. The ceiling is set by design; the distance you fall below it is set by details.

The second is a floor. The succinct systems here are not "proofs" in the strongest sense at all; they are arguments.

A *proof* is sound even against an adversary with unlimited computing power: a false statement simply cannot be proved. An *argument* is only *computationally* sound: forging a proof of a false statement is possible in principle but requires breaking a hardness assumption, so no feasible attacker can do it. Every succinct system deployed by Zcash or Monero is an argument. Its soundness rests on a problem being hard -- pairings and knowledge-of-exponent for Groth16, discrete log for inner-product arguments, Bulletproofs, ring signatures, and Curve Trees.

That floor is load-bearing, and BCTV14 is the proof of it. The argument was accepted mathematics, and it was unsound, and the only thing standing between "unsound argument" and "silent counterfeiting" was the aggregate turnstile [@ecc-postmortem]. An argument is a promise conditional on an assumption, and a conditional promise can fail two ways: the assumption is false, or the reduction to it is buggy.

The third limit is the one place the field genuinely closed a practical gap -- and it is the single most mis-stated fact in popular writing about these systems, so state it exactly. You will often read that pairing-based SNARKs "provably require" a structured reference string while transparent systems use "no setup at all." Both halves are wrong, and the correct statement is older and more fundamental.

Non-interactive zero-knowledge was defined by Blum, Feldman, and Micali in 1988 relative to a shared common reference string -- setup was baked into the model from the start [@blum-feldman-micali-1988]. And Goldreich and Oren proved in 1994 that non-interactive zero-knowledge in the plain model, with no shared setup at all, exists only for trivial (BPP) languages -- so a non-interactive zero-knowledge argument for any non-trivial language must have some common setup: a common reference string or a random oracle [@goldreich-oren-1994]. Every system here therefore has a setup. The only question is whether you must trust it.

A pairing SNARK like Groth16 uses a structured reference string whose secret randomness is toxic waste, which is why it needs a ceremony. Transparent arguments -- Halo 2's inner-product argument, Bulletproofs, Curve Trees -- use a public, untrusted setup: nothing-up-my-sleeve generators and public hash functions that hide no secret and need no ceremony. The advance is not "no setup"; it is "setup nobody has to trust," and it now comes at transaction sizes within a small constant of trusted-setup SNARKs -- roughly 4 KB (with a 2.9 KB membership proof) against Sapling's 2.8 KB transaction [@ecc-halo2] [@curve-trees] [@stanford-bulletproofs]. The toxic-waste break class is not mitigated here; it is removed.

Note: The correct impossibility is not "pairing SNARKs need a trusted setup and transparent ones need none." It is that non-interactive zero-knowledge for any non-trivial language needs some common setup at all -- a common reference string or a random oracle (Blum-Feldman-Micali 1988; Goldreich-Oren 1994) [@blum-feldman-micali-1988] [@goldreich-oren-1994]. Trusted-setup and transparent systems differ only in whether that setup must be trusted: a structured reference string hides toxic waste, a transparent public setup hides nothing. Say "no trusted setup," never "no setup."

One more subtlety belongs here, because it is routinely conflated with the setup question. SNARK succinctness itself cannot be proved secure from standard falsifiable assumptions by black-box reductions -- Gentry and Wichs showed any such argument must instead rest on non-falsifiable "knowledge" assumptions or an idealized model like the random oracle [@gentry-wichs-2011]. That is a statement about the assumptions a short proof needs, not about whether its reference string is structured.

Put the three together and the honest reading is bracing: a succinct argument leans on a strong assumption to exist at all, on a hardness assumption to be sound, and on some public setup to be non-interactive. Removing the trusted part of the setup, as Halo 2 and Curve Trees do, is a real and hard-won advance -- but it removes exactly one of those three dependencies, not all of them.

It is tempting to file every privacy technology under "zk-SNARK," but the family is broader than that. [Direct Anonymous Attestation](/blog/direct-anonymous-attestation-the-zero-knowledge-proof-alread/) -- the scheme that lets a hardware security chip prove it is genuine without becoming a tracking beacon, covered elsewhere in this corpus -- is a zero-knowledge *proof of knowledge*, but it is an *interactive sigma-protocol* in the Schnorr and Camenisch-Lysyanskaya tradition, not a succinct non-interactive argument [@daa-ccs-2004]. Same broad idea of proving a secret without revealing it; entirely different construction, assumptions, and break conditions. When someone says "it uses zero-knowledge proofs," always ask which kind. Every deployed system here rests on discrete log or pairings -- both fall to a large quantum computer, and soundness and privacy fail on different clocks. A future quantum adversary could forge proofs -- but a *store-now, decrypt-later* adversary threatens today's *privacy* the moment it records the chain, because the hiding also rests on discrete log. The same logic drives migration to lattice schemes (ML-KEM, ML-DSA) and hash-based signatures (SLH-DSA) [@nist-pqc-2024], examined in the corpus's "how X would break" post-quantum entries. FCMP++'s "forward secrecy" targets exactly this: it protects privacy against a future discrete-log oracle, though its soundness is not post-quantum [@fcmp-blog].

Every one of these limits is the thesis restated at the level of theory: the ceiling is the set your proof ranges over, the floor is the soundness your argument rests on, and even the one problem the field solved was solved only in part -- the setup stayed, but the trust in it went away. So if the ceiling is the set and the floor is soundness, where do today's systems still leak?

10. Where the Proofs Still Leak

Every unsolved break condition in this field is just a proof not yet strong enough, or a leak the proof was never meant to cover. Five stand out.

Decoy realism (Monero). Choosing ring decoys so that no statistical test -- age, chain-reaction, timing -- beats $1/N$ is the entire security of the ambiguity model, and it is never provably perfect. Mandatory RingCT, zero-decoy elimination, larger rings, and gamma-distributed selection blunted the Moser attacks but did not end the arms race [@moser-popets2018]. The clean resolution is to stop selecting decoys at all, which is exactly what a full-chain membership proof does [@fcmp-blog].

Shielded-pool adoption (Zcash). Making the effective set approach the nominal pool is an incentive and user-experience problem, not a cryptographic one. A perfectly sound proof over a thin, founder-dominated pool yields little real anonymity [@kappos-usenix2018]. Cheaper shielding and better wallets help, but as long as transparent addresses exist and shielding is opt-in, the pool's composition stays a live analysis target.

The network layer. No on-chain proof hides who broadcast a transaction. IP and timing metadata sit entirely outside both constructions, and they defeat privacy at the peer-to-peer layer for Zcash and Monero alike. Dandelion++ raises the cost of first-relayer deanonymization, but remote-node and light-wallet usage still leaks [@dandelionpp-2018].

Dandelion++ is a network-layer defense, not a cryptographic one: it splits transaction propagation into a randomized "stem" phase before the public "fluff" broadcast, so the first node to see a transaction cannot easily be assumed to be its origin [@dandelionpp-2018]. It is a genuine improvement, but it protects a surface -- who broadcast -- that ring signatures and zk-SNARKs never claimed to cover, which is exactly why it belongs on a separate layer of the map below.

Formal verification of the deployed circuit. BCTV14 was a flaw in the construction as described, invisible to expert review for years, so auditing the abstract scheme is not enough -- you must audit the deployed circuit. The 2024 Cypher Stack review of CLSAG found two gaps in its security proof with no impact on the Monero implementation, a reassuring near-miss [@clsag]. Less reassuring: FCMP++'s Generalized Bulletproof soundness proofs were still being written at proposal time, and that risk runs straight back to Gabizon's redundant-CRS-element discovery [@fcmp-ccs] [@gabizon-2019-119]. The gap between "implemented" and "proven sound" is the BCTV14 gap, reopened for the successor.

Post-quantum private payments. No deployed private coin is post-quantum sound at competitive cost, and a store-now-decrypt-later adversary threatens privacy today. FCMP++'s forward secrecy protects privacy against a future discrete-log oracle but leaves soundness classical [@fcmp-blog]. This is the same pressure that the corpus's "how X would break" post-quantum entries trace across ML-KEM, Falcon, and SLH-DSA, and it is the most pressing open problem here.

flowchart TD OnChain["On-chain proof: is the argument sound?"] Set["Anonymity set: is it large and real?"] Net["Network layer: who broadcast the transaction?"] Circuit["Circuit: is the deployed code actually sound?"] PQ["Post-quantum: does a quantum solver break it?"] Legal["Legal: are you allowed to trade it at all?"] Q{"Anonymous against whom?"} OnChain --> Q Set --> Q Net --> Q Circuit --> Q PQ --> Q Legal --> Q

The frontier tying several of these together is FCMP++, and it deserves an honest description because the hype around it is wrong in a specific way. It would replace the ring of sixteen with a zero-knowledge membership proof over every output on the chain, taking each input's anonymity set from sixteen to roughly 100,000,000, with no trusted setup, on a transparent Curve-Trees accumulator [@fcmp-blog] [@curve-trees] -- with a reference implementation taking shape in the monero-oxide Rust codebase [@monero-oxide]. In doing so it converts the ambiguity school into the proof school and inherits its break condition: the soundness of a Generalized Bulletproof [@fcmp-ccs].

Note: Watch the exact swap. Today's Monero has a small, sometimes-collapsible anonymity set but no proof-soundness assumption to break, because it makes no cryptographic claim about which output was spent. FCMP++ would give it the whole chain -- closing the set gap for good -- but only by adding a Generalized Bulletproof whose soundness must then hold, reopening a soundness gap of exactly the kind that bit BCTV14. That is not a criticism; it is the thesis in action. You do not get anonymity for free; you choose which break condition you would rather carry [@fcmp-ccs] [@fcmp-blog].

Note: As of 19 July 2026, FCMP++ is specified, funded, and under audit -- but not deployed. The current Monero release is 0.18.5.1 "Fluorine Fermi," and consensus is still CLSAG ring signatures with a ring of sixteen; there is no FCMP hard fork [@monero-release-blog]. Any claim that Monero already has full-chain anonymity in production is false. Today's Monero user has a ring of sixteen, not the whole chain [@fcmp-ccs].

One of the quiet pleasures of this history is a revival. The inner-product argument "famously used in Bulletproofs" -- the ambiguity school's 2018 tool for shrinking Monero's range proofs -- is the same primitive Zcash built Halo 2 on in 2022 to eliminate trusted setup. The efficiency trick of one school became the other school's route to a cleaner proof [@ecc-halo2] [@bulletproofs-sp2018].

Even a perfect proof over the entire chain, though, runs into one break condition that no cryptography can touch -- and by 2026 it is the sharpest of them all.

11. The Anonymity You Are Allowed to Prove

After a decade of tightening the cryptography, the sharpest live break condition for both coins is not a soundness flaw or a collapsible ring. It is a statute. Through 2024, 2025, and 2026, major exchanges operating in the European Union -- Binance, Kraken, OKX, and others -- delisted or restricted Monero, Zcash, and similar assets [@binance-delisting]. The delistings are real and current. What matters for anyone reasoning clearly is attributing them to the right instruments, because the popular shorthand "MiCA banned privacy coins" is wrong on every word.

Instrument	What it actually does	Key date	Effect on privacy coins
MiCA, Regulation (EU) 2023/1114	A market-conduct, transparency, and licensing regime for crypto-asset service providers	CASP provisions apply from 30 December 2024	Compliance pressure and cost; contains no privacy-coin ban [@mica-2023-1114]
AMLR Article 79, Regulation (EU) 2024/1624	Prohibits obliged entities from keeping anonymous crypto-asset accounts and anonymity-enhancing coins	Applies from 10 July 2027	The actual prohibition, binding service providers, not individuals [@amlr-2024-1624]
FATF Recommendation 16 and EU TFR 2023/1113	Requires originator and beneficiary information to travel with each transfer	In force in the EU	The global driver that makes traceless coins hard to service [@tfr-2023-1113] [@fatf-va]

MiCA (Regulation (EU) 2023/1114) is a licensing and market-conduct framework. It raises the compliance cost of listing a hard-to-trace asset, and exchanges cite it when they delist, but it contains no prohibition on privacy coins [@mica-2023-1114]. The dated prohibition lives in the Anti-Money-Laundering Regulation: Article 79(1) of Regulation (EU) 2024/1624 bars credit institutions, financial institutions, and crypto-asset service providers from keeping "anonymous ... crypto-asset accounts as well as any account otherwise allowing for the anonymisation ... or increased obfuscation of transactions, including through anonymity-enhancing coins," applying from 10 July 2027 [@amlr-2024-1624].

The driver underneath both is FATF Recommendation 16, the Travel Rule, implemented in the EU by TFR 2023/1113, which requires identifying information to accompany transfers -- the one thing a traceless coin structurally cannot provide [@tfr-2023-1113] [@fatf-va]. Say "AMLR Article 79," not "MiCA," when you mean the ban.

Zcash and Monero are the canonical constructions, but the same regime sweeps up their relatives, each a variant of the two schools here. Dash offers non-custodial CoinJoin mixing through masternodes -- ambiguity by shuffling, closer to the 2013 pre-history than to either coin [@dash-coinjoin]. Firo's Lelantus Spark is a no-trusted-setup membership-proof scheme, a descendant of the very Zerocoin that was later broken, rebuilt as a proof [@lelantus-spark]. Beldex is a Monero-lineage CryptoNote/RingCT coin [@beldex]; Pirate Chain uses always-shielded Zcash-Sapling zk-SNARKs [@pirate-chain]. Every one inherits a construction from this article and, from 10 July 2027, the same legal break [@amlr-2024-1624].

The thesis reaches its final form here. A provable anonymity and a permitted anonymity are different properties, and the second is not something cryptography can supply. No cryptographic advance postpones the 10 July 2027 deadline [@amlr-2024-1624]. There is a genuine irony in the one technical escape hatch: both systems already support selective disclosure -- Zcash and Monero view keys -- that let a holder voluntarily reveal a transaction to an auditor or regulator [@zcash-viewkeys] [@monero-viewkey].

But that is precisely the disclosure these constructions spent a decade proving you need not make. Using it to satisfy a compliance adversary is not a break in the proof; it is a decision to stop relying on the proof. A fittingly honest place to land before turning the whole argument into something you can use.

The delisting notices themselves are anchored here to the MiCA and AMLR primary texts rather than to individual exchange announcements, several of which are bot-gated or geo-restricted and could not be independently confirmed. The legal drivers are the load-bearing claim; any single exchange notice is illustrative [@mica-2023-1114] [@amlr-2024-1624] [@binance-delisting].

So how should an engineer actually reason about any of this on a Monday morning?

12. Reasoning About On-Chain Anonymity

One question collapses almost all of the marketing around privacy coins: anonymous against whom, within which set, under which proof? If a claim cannot answer those, it is not an engineering statement. The whole article reduces to a four-line checklist you can run against any construction, deployed or promised.

Ask	What you are establishing	Zcash answer	Monero answer
What is proved?	A cryptographic soundness proof, or a statistical claim of ambiguity	A zk-SNARK: the spend is valid and hidden	Ambiguity: the spend is one of N
Over which set?	The nominal set size, and the effective size after heuristics	All shielded notes, but thin in practice [@kappos-usenix2018]	A ring of 16, effective and often smaller [@moser-popets2018]
Against which adversary?	Casual observer, chain-analysis firm, network watcher, or a compliance authority	Sound vs a chain analyst if you shield; opt-in	Always-on vs a chain analyst; realism-bounded
What is the break condition?	The single assumption whose failure collapses the guarantee	Unsound proof, or a set too small	A guessable real spend

Run that checklist and the design choices sort themselves:

Want the smallest proof and cheapest verification, and can accept a trusted-setup lineage plus opt-in privacy? Zcash Sapling / Groth16.
Want strong hiding with no ceremony to trust, plus recursion for scale, still opt-in? Zcash Orchard / Halo 2 -- today's recommended pool [@ecc-halo2].
Want always-on, no-setup, uniform privacy now, and can accept a bounded ring of sixteen with residual decoy risk? Monero RingCT / CLSAG / Bulletproofs+ -- deployed.
Want a full-chain, transparent membership proof, the honest endgame of the ambiguity school? Monero FCMP++ -- once it is deployed and its Generalized Bulletproof soundness is proven, which is not today [@fcmp-ccs] [@curve-trees].
Facing a compliance or legal adversary (an exchange or custodian)? None is "permitted"; the break is regulatory, not cryptographic -- AMLR Article 79 and the FATF Travel Rule, not a soundness bug [@amlr-2024-1624].

The single most common Zcash misconception is "I hold ZEC, so I am private." Privacy in Zcash is a property of *transactions that entered the shielded pool*, not of the asset. To check, trace each receiving address on a block explorer: an address beginning with `t` is transparent, and every amount and counterparty is public; a `z` (Sapling) or unified address that received a *shielded* output is the only value the zk-SNARK actually hides.

If your coins arrived at a transparent address and never made a shielded (z-to-z) hop, the proof never ranged over them -- you have the pool's cryptography and none of its anonymity. The same logic is why Kappos et al. could measure the pool from outside: the transparent-to-shielded boundary is itself public [@kappos-usenix2018].

No. Zcash is transparent by default, and the shielded proof only ranges over value that has actually entered the shielded pool -- which most ZEC never does. Measurements found only about 15% of transactions ever touched the pool, and simple heuristics cut the effective anonymity set substantially [@kappos-usenix2018]. Privacy in Zcash is real but opt-in, and it is only as large as the set you actually join. It is statistically ambiguous, not unconditionally untraceable. Early decoy selection made the real spend guessable -- roughly 62% of inputs with a mixin were deducible by chain-reaction, and the newest ring member was the real one about 80% of the time [@moser-popets2018]. Mandatory RingCT, larger rings, and realistic decoy sampling mitigated these attacks, but the guarantee remains statistical and the ring is bounded at sixteen. No. MiCA (Regulation (EU) 2023/1114) is a market-conduct and licensing framework with no privacy-coin prohibition; it is pressure, not a ban [@mica-2023-1114]. The actual prohibition is AMLR Article 79 (Regulation (EU) 2024/1624), which bars service providers from keeping anonymity-enhancing coins and applies from 10 July 2027 [@amlr-2024-1624]. No. The trusted-setup secret ("toxic waste") governs the proof system's soundness, not its privacy. A leaked setup would let an attacker counterfeit value, which is serious, but it is not a key that deanonymizes anyone's transactions. Transparent systems like Halo 2 and Bulletproofs remove the *trusted* part of the setup entirely [@ecc-halo2]. There is no evidence it was. In-pool counterfeiting would have been cryptographically undetectable, but the turnstile that meters net value crossing the pool boundary showed no aggregate anomaly, and Sapling superseded the flawed circuit before the vulnerability was disclosed on 5 February 2019 [@ecc-postmortem]. Only against the right adversary. A larger, uniform ring blunts size-fingerprinting and the guess-newest heuristic, but the guarantee stays statistical and bounded, and the realism of the decoys matters more than the raw number. Sixteen realistic decoys beat sixty-four obvious ones [@moser-popets2018]. Not as of 2026. The current release is 0.18.5.1 "Fluorine Fermi," with ring signatures still in consensus [@monero-release-blog]. FCMP++ would raise each input's anonymity set to roughly 100,000,000, but it trades Monero's statistical assumption for the soundness of Generalized Bulletproofs, whose proofs were still being formalized at proposal time [@fcmp-ccs] [@fcmp-blog].

Key idea: The Monday-morning version of the whole argument: before you trust any on-chain anonymity, name the proof. If it is a cryptographic proof, its break is unsound math or a set too small to hide in. If it is statistical ambiguity, its break is a guessable real spend. Then name the adversary, and check whether the effective set -- not the advertised one -- still hides you against that adversary. Name the proof, and you have named the break.

Two coins, two constructions, two break conditions that turned out to be the same statistical shape underneath -- and, waiting past every proof, a legal wall no cryptography can climb. The lesson is not that one coin is more private than the other. It is that "private" was never a single property. It is a proof with an assumption attached, and the assumption is always nameable. That is the discipline worth keeping: not "is it anonymous?" but "what does it prove, and what breaks when that proof's one assumption fails?"

Name the proof, and you have named the break.