# Aztec Says a Flaw in Its Proving System Puts Funds on Its Live Privacy Network at Risk

Core contributors found the defect through internal artificial-intelligence-assisted auditing, and say the validator committee's public re-execution cannot catch it.

- Published: 2026-08-14T05:52:13.666Z
- Canonical: https://polylog.news/crypto/2026-08-14/aztec-says-a-flaw-in-its-proving-system-puts-funds-on-its-li
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network (disclosure)](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network (Alpha V5)](https://aztec.network/alpha-v5), [Aztec Network (ecosystem)](https://aztec.network/blog/dark-forest-aztec-game-goes-live)

Aztec, the privacy-focused layer-2 network on Ethereum, has [disclosed a critical vulnerability in the proving system](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) behind Alpha V5, the version of its network that governance activated after the upgrade cut the cost of proving a private transaction in half.

The defect is a soundness failure, not a leak of private data. According to the disclosure, an attacker may be able to construct a proof that passes verification for a transaction the network should reject. If the network accepted such a proof, the resulting state transition would fall outside the rules V5 is supposed to enforce. Contributors say they cannot determine whether anyone exploited the flaw before they found it. They advise treating funds, applications and contract state on [Alpha V5](https://aztec.network/alpha-v5) as exposed to a protocol-level failure until incident response finishes and node operators complete the required network actions.

Two details matter more than the bug itself. First, contributors say they found it through internal auditing assisted by artificial-intelligence tooling, the same class of review that is now surfacing defect backlogs across open-source cryptography. Second, they state that the flaw is not mitigated by public re-execution by the committee of validators. Re-execution is the fallback most rollups rely on when a prover misbehaves, because honest nodes can recompute a disputed block. A proof that verifies for an invalid statement defeats that check, because there is nothing for validators to disagree about at the level they inspect.

This is the second proving-system emergency in Aztec's alpha cycle. Contributors disclosed a critical vulnerability in Alpha V4 earlier this year and told users to withdraw before the V5 governance vote made the V4 details public. V5 was the fix. The network is explicitly labelled alpha software, and a V6 release is planned for later this year alongside a published security roadmap, but the ecosystem around it is already live, including [applications and games running on the network](https://aztec.network/blog/dark-forest-aztec-game-goes-live).

The core problem is that privacy networks carry a compounding verification burden. A transparent rollup can be audited by anyone who replays the chain. A private one cannot, so the proof system is not one safeguard among several, it is the safeguard. That raises the cost of shipping and lengthens the path from alpha to a network that custodians and institutions will hold balances on.

## What this means

Soundness bugs in zero-knowledge proving systems hit a failure surface that neither audits of application code nor validator re-execution covers, so the people exposed are users holding balances on proof-dependent networks and the teams whose token value depends on those networks advancing beyond alpha status. Two outcomes are possible from here. Either Aztec patches and upgrades without evidence of exploitation, and the episode reads as alpha software working as labelled, or an on-chain trace of abuse appears, in which case every privacy rollup faces harder questions from custodians about holding assets behind a single proof system.

## What to watch

- Whether Aztec publishes evidence that no invalid state transition was accepted before the fix, which is the difference between a disclosed near-miss and a realised loss.
- Whether other zero-knowledge rollups announce proof-system diversity or independent verifier implementations, a sign that teams now treat single-prover designs as a concentrated risk rather than an engineering convenience.
- How quickly node operators complete the required upgrade, since a slow rollout leaves the vulnerable version live while the defect is public.