# Aztec Discloses a Soundness Flaw in Its Alpha v5 Proving System

Core contributors found that an attacker could construct a proof that verifies for a transaction the network should reject, and the fix is scheduled for the next version rather than a patch to the live alpha.

- Published: 2026-09-08T05:45:27.037Z
- Canonical: https://polylog.news/crypto/2026-09-08/aztec-discloses-a-soundness-flaw-in-its-alpha-v5-proving-sys
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network](https://aztec.network/alpha-v5)

Aztec, the privacy-focused Ethereum layer-2 network, disclosed a critical vulnerability in the proving system of its [Alpha v5 release](https://aztec.network/alpha-v5). In Aztec's description of the flaw, an attacker could build a proof that passes verification for a transaction the network is supposed to reject. That is a soundness break rather than a smart-contract bug, and it is the failure class that matters most for a chain where validity proofs, not re-execution by validators, are what keep the ledger honest.

Aztec said core contributors identified the defect through internal auditing assisted by artificial intelligence, after internal and external human audits of the same code had already completed. The team frames the finding as the purpose of an alpha period and has scheduled the [remediation for the next version](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) rather than shipping an emergency patch, which follows the pattern it used for a comparable proving-system flaw in Alpha v4, disclosed only once users had been told to withdraw.

That disclosure policy is the contested part. Embargoing details until an upgrade lands protects users from an attacker reading the advisory first. It also means the people holding funds on the live network are asked to trust a team's private assessment of a bug they cannot evaluate. For a privacy chain, the tension is sharper than usual, because shielded balances make it harder for outside observers to confirm whether an exploit has already occurred.

A soundness bug in a zero-knowledge system is also structurally different from a contract exploit. On an optimistic rollup, honest parties can re-execute transactions and dispute a bad state root. On a validity rollup, a proof that verifies is accepted, so no fallback catches a forged proof. That is why proof-system diversity, escape hatches and slow upgrade paths have become the standard mitigations rather than faster patching.

## What this means

Zero-knowledge proving stacks are now a distinct risk category from the smart contracts running on top of them, and the exposure sits with anyone holding assets on a validity rollup, including the privacy networks seeking institutional users. Two outcomes are possible from here. Either teams standardize on embargo-plus-scheduled-upgrade disclosure and users accept opaque risk windows, or funds concentrate on rollups that ship escape hatches and multiple independent provers. The finding also strengthens the case that automated code analysis catches defects that funded human audits miss, which raises the expected number of such disclosures across the sector.

## What to watch

- Whether Aztec publishes the technical detail of the flaw when the fixed version ships, which is the only way outside researchers can judge how close the network came to a forged proof.
- Whether other zero-knowledge rollups disclose soundness findings from artificial-intelligence-assisted review, which would confirm this is a systematic backlog rather than one team's bad luck.
- Adoption of multiple independent provers and user escape hatches on validity rollups, since those are the only mitigations that work when a proof verifies but should not.