A vendor pitches a "zero-knowledge" compliance product to a risk committee, and someone on the committee asks the only question that matters: what, exactly, does this prove? The honest answer is narrower than the pitch. A zero-knowledge proof establishes that a specific computation was carried out correctly on some inputs, without revealing those inputs. It does not establish that the inputs were true, that the party supplying them behaved honestly, or that the software implementing the proof is free of defects. "The maths checks out" and "the underlying facts are correct" are different claims, and the first does not carry the second.
What the proof actually covers
A zero-knowledge proof lets one party, the prover, convince another, the verifier, that a statement about some hidden input is true, without the verifier learning the input itself. In an institutional setting the statement is usually arithmetic: "these account balances sum to this total," "this signature was produced by a key controlling this address," "this transaction passed a sanctions screen." Provided the underlying cryptographic assumptions hold and the system is correctly built, a false statement cannot be proved true except with negligible probability.
What sits outside that guarantee is everything upstream of the statement. If the input data was wrong, incomplete or fraudulently entered, a correctly generated proof will faithfully certify a correct computation over bad data. This is the boundary drawn in our coverage of reserve attestations: a cryptographic proof of an aggregate balance cannot show that no liability was left out of the data it was computed over, that the reserve assets are unencumbered, or that the position holds beyond the moment of the snapshot (proof of reserves: what it proves). The same logic applies wherever a ZK-based control is offered as evidence of compliance: it proves the control executed as specified, not that the specification, or the data fed to it, was right.
SNARKs, STARKs and the trusted-setup question
Two families of general-purpose proof systems dominate deployment. SNARKs (succinct non-interactive arguments of knowledge), in constructions such as Groth16, produce small proofs that are cheap to verify on-chain. Their cost is that they have typically required a trusted setup: a one-time ceremony that generates public parameters from secret randomness, often called "toxic waste", which must then be destroyed. Anyone who obtains that secret can forge proofs. The usual mitigation is a multi-party ceremony in which each participant holds a share, so that the setup is safe as long as at least one participant genuinely deletes theirs, as a February 2022 review of zk-SNARKs sets out. STARKs (scalable transparent arguments of knowledge) need no trusted setup, rely on collision-resistant hash functions, and are regarded as resistant to quantum attacks that would break the elliptic-curve assumptions SNARKs rely on. The trade-off is that STARK proofs are far larger, which makes on-chain verification slower and more expensive in gas.
Proving cost is the other side of the ledger. Generating a proof is far more expensive than running the computation it describes, and it is where vendors compete. StarkWare announced its S-two prover on 26 May 2025, claiming it outperformed competing provers by 10 to 30 times depending on the task, and was 39 times faster than an SP1 precompile on a Keccak-hashing benchmark. On 3 November 2025 Starknet said S-two was live on its mainnet, replacing the Stone prover, and that it generated proofs up to an order of magnitude faster than Stone, in seconds for computations that previously took minutes. These are the vendor's own benchmarks, not independently audited figures, and they say nothing about any specific production workload. Verification, by contrast, is designed to be cheap: the verifier checks the proof without re-running the computation, which is the point of "succinct".
Where it is actually deployed
Validity rollups
The most mature deployment is the validity, or "ZK", rollup: a layer-2 network that executes transactions off the base chain and submits a proof that a contract on the base chain verifies before accepting the new state. Starknet's STARK-based Alpha went live on Ethereum mainnet on 29 November 2021, supporting general-purpose smart contracts that could message contracts on Ethereum itself. Aztec's privacy-focused Ignition Chain went live on Ethereum on 20 November 2025 after its validator queue reached 500; anyone can become a validator or sequencer by staking AZTEC tokens. The architecture, and the optimistic-versus-validity distinction, are covered separately (Ethereum layer-2 rollups explained). What matters here is that a validity proof removes the challenge period but not the question of who runs the prover and the upgrade keys, taken up under failure modes below.
Private transactions
Zcash's shielded transactions use zk-SNARKs to hide amounts and counterparties while still proving that each transaction obeyed the protocol's rules. For a regulated institution, "private" and "compliant" are not synonyms, and the distinction between confidentiality, identity and auditability is set out in our piece on privacy for regulated finance (blockchain privacy in regulated finance). At Proof of Talk Paris 2026, a Taostats Stage panel titled "Privacy and Compliance: Two Sides of the Same Coin" brought together James Smith of Elliptic, Jody Mettler of BitGo, Jens Hachmeister of Clearstream, Deutsche Börse Group, and Dr Saj Khoshroo of Midnight, with Nicola Massella of Storm moderating.
Selective disclosure of credentials
EU digital identity policy shows the gap between naming a technology and requiring it. The revised eIDAS Regulation, (EU) 2024/1183, has been in force since 20 May 2024, and member states must be able to offer citizens a European Digital Identity Wallet by the end of 2026; that obligation is adopted but not yet applying. The wallets must support selective disclosure, so a person can prove, for instance, that they are over eighteen without revealing their date of birth. Recital 14 says member states "should" integrate privacy-preserving technologies such as zero-knowledge proofs, but a July 2025 analysis in Internet Policy Review is precise about what that commits anyone to: ZKPs are not mandatory, and "are also not required in the latest version of the architecture and reference framework", the technical specification implementers build against. At that time the framework relied on two selective-disclosure formats based on salted hashes, an IETF JSON-based one and the ISO mobile-document standard, neither of them a zero-knowledge proof. Vendor material sometimes blurs "named in a recital" and "required in the specification"; only the second obliges a wallet provider to build anything.
Proof of reserves and solvency
A zk-SNARK layer lets an exchange or custodian prove that a set of individually hidden account balances sums to a published total and that no included account is negative. That is an improvement on a bare Merkle-tree attestation, but it carries the same snapshot and completeness limits (proof of reserves: what it proves). Confidential computing attacks a similar class of problem with hardware and different trust assumptions (confidential computing and trusted execution).
What goes wrong
Circuit bugs
A zero-knowledge proof is only as sound as its circuit, the arithmetic encoding of the statement being proved, and circuits are easy to get subtly wrong. The zk-bug-tracker maintained by 0xPARC catalogues more than two dozen disclosed defects in deployed or audited systems, among them an under-constrained circuit in the MACI 1.0 voting system found by the Privacy and Scaling Explorations security team, and several missing-constraint bugs in Polygon zkEVM found in audits by Spearbit and Hexens. The common pattern is the under-constrained circuit: a value the prover should be forced to fix is left free, so a dishonest prover can choose another and still pass verification, proving something happened when it did not. Such a flaw sits in the proof system itself, beneath any smart contract built on it.
Setup and parameter flaws
The clearest dated incident is Zcash's BCTV14 vulnerability. According to the Electric Coin Company, Ariel Gabizon, a cryptographer then employed by the Zcash Company, discovered on 1 March 2018 that the parameter-generation procedure produced extra elements that let a cheating prover circumvent a consistency check and turn a proof of one statement into a valid-looking proof of another. Anyone with access to the setup ceremony's transcript could have used it to create unlimited counterfeit shielded tokens. The company kept the flaw confidential, fixed it in the Sapling network upgrade activated on 28 October 2018, told Horizen and Komodo, which ran affected code, on 13 November 2018, and disclosed it publicly on 5 February 2019. It found no evidence that anyone else had discovered the flaw or that counterfeiting had occurred. The lesson for a risk committee is that the setup is a risk beyond the secrecy of the toxic waste: the published parameters themselves can be wrong in ways that take months to find.
Prover and operator centralisation
The newest failure mode is not a broken proof but a sound one controlled by too few parties. L2BEAT's classification, checked on 23 September 2026, puts ZKsync Era, Scroll and Linea at Stage 0, the "training wheels" stage in which a rollup relies heavily on centralised entities such as the project team or operator for state validation, sequencing and upgrades. Starknet is at Stage 1, which requires working proofs and a security council whose sign-off needs a supermajority including external members; Aztec is listed at Stage 2. A flawless proof system can still sit inside an operational trust model with a single point of failure, much as a single-custodian arrangement can.
Questions worth putting to a vendor
- What statement, precisely, does the proof cover, and what is assumed rather than proved about the data feeding it?
- Is the proof system SNARK- or STARK-based, and if it needed a trusted setup, who took part in the ceremony?
- Has the circuit been independently audited, and against which known bug classes, such as under-constrained signals?
- Who can generate a valid proof today, and what happens if that party stops or is compromised?
- Who holds the upgrade and override keys?
None of this is tax, legal or investment advice; the questions above are a starting point for the conversation with counsel and with the vendor.