# Aztec Discloses a Soundness Flaw That Let a Valid Proof Authorize an Invalid Transaction

Core contributors found the defect in the live Alpha V5 privacy network on 27 July using internal artificial-intelligence-assisted auditing, and the fix ships with V6.

- Published: 2026-09-15T05:52:11.664Z
- Canonical: https://polylog.news/crypto/2026-09-15/aztec-discloses-a-soundness-flaw-that-let-a-valid-proof-auth
- 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 Network](https://aztec.network/blog/dark-forest-aztec-game-goes-live)

Aztec, the privacy-focused layer-2 network on Ethereum, has published a disclosure describing a critical defect in the proving system behind its live Alpha V5 release. According to [the team's write-up](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), an attacker could construct a proof that passes verification for a transaction the network is supposed to reject, producing a state transition outside the rules the protocol intends to enforce. Core contributors identified the flaw on 27 July through internal auditing assisted by artificial intelligence, and the repair is scheduled for the V6 release.

This is a soundness failure, not a bug in an application contract. In a zero-knowledge rollup, the proof is the only check between a submitted transaction and the network's accounting of who owns what. Optimistic rollups can fall back on other participants re-executing transactions and challenging a bad result. A proof-based system cannot, because there is nothing to re-execute if the verifier accepts a fraudulent proof as valid.

The disclosure follows the same pattern as Aztec's [March disclosure of a critical vulnerability in Alpha V4](https://aztec.network/blog/critical-vulnerability-in-alpha-v4), which the team said affected the proving system as a whole and could enable theft of user funds. In both cases Aztec withheld details until a fixed version was ready, and [told V4 users to withdraw](https://thedefiant.io/news/defi/aztec-v4-withdraw-june-25-v5-upgrade-security-vulnerability) before the disclosure went public.

Aztec has been explicit that its [Alpha releases](https://aztec.network/alpha-v5) are test-phase software, with applications such as [an on-chain game running on the network](https://aztec.network/blog/dark-forest-aztec-game-goes-live) and a bug bounty raised to $2 million. The straightforward reading is that the disclosure process worked as designed. The less comfortable reading is that two consecutive versions of a production-labeled privacy network shipped with proof defects that only internal review caught.

## What this means

Proof-based chains concentrate their entire security assumption into one piece of cryptographic machinery, so a soundness bug is not a loss capped at one contract's balance but a defect in the ledger's own accounting. Users of privacy rollups are exposed through the withdrawal path, because a forged state transition can move funds before anyone can observe it, and the confidentiality that makes these networks valuable also removes the on-chain trail that lets outsiders detect the theft. Teams that publish on this timeline face a second cost: every embargo period is a stretch of time during which insiders know more than depositors.

## What to watch

- Whether Aztec publishes the specific technical detail of the V5 defect once V6 is live, which is the test of whether the embargo was about user safety or reputation.
- Whether other zero-knowledge rollups add a second, independently written proof verifier, the standard answer to a single-implementation failure.
- Whether internal artificial-intelligence-assisted review keeps finding these defects before outside researchers do, which would shift where security budgets go across the sector.