Aztec Discloses a Critical Flaw in the Proving System Behind Its Live Privacy Network

Aztec, the privacy-focused Ethereum layer-2 network, has disclosed a critical vulnerability in the proving system of its Alpha V5 network. Core contributors identified the flaw on July 27 through internal auditing assisted by artificial intelligence. According to the disclosure, an attacker could build a proof that passes verification for a transaction the network should have rejected. Reviewers have not identified other high-severity or critical issues in V5 at this time, and internal and external human audits have completed while machine-assisted review continues.

The timing is uncomfortable. Alpha V5 launched on July 21 after a governance vote, bringing a fully private execution environment and roughly halved proving costs. The flaw was found six days later.

This is the second consecutive version to carry a proving-system defect. Aztec found a critical bug in Alpha V4 in March, and under its transparency commitments it disclosed the details when the V5 upgrade proposal went on-chain, telling V4 users to withdraw before the late-June cutoff. Of that earlier bug the team wrote that it affected the proving system as a whole and was not mitigated by public re-execution by the committee of validators.

That finding is the important one, and it applies beyond Aztec. Most rollups treat validator re-execution as the backstop that catches a bad state transition. A soundness defect in the proof system itself defeats that backstop, because the fraudulent transition arrives with a proof the verifier accepts. It is a distinct risk from a smart-contract exploit, it cannot be found by auditing application code, and it forces teams into embargoed disclosure timed to an upgrade rather than an immediate public warning.

The evidence here supports two readings at once. Aztec is running an explicitly labeled alpha, it is publishing what it finds, and machine-assisted review is surfacing defects that human audits missed. Against that, users hold funds on a live network whose security depends on a component that has now failed review twice, and the product surface keeps expanding while the proving stack is still under repair.