# Aztec Says a Flaw in Its Alpha V5 Proving System Could Let an Invalid Transaction Pass Verification

Core contributors found the defect on July 27 through internal artificial-intelligence-assisted auditing and say they cannot determine whether anyone exploited it first.

- Published: 2026-08-28T05:39:41.604Z
- Canonical: https://polylog.news/crypto/2026-08-28/aztec-says-a-flaw-in-its-alpha-v5-proving-system-could-let-a
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network (Alpha V5)](https://aztec.network/alpha-v5)

Aztec, a privacy-focused layer-2 network on Ethereum where private functions are executed and proven on the user's own device, has disclosed a critical defect in the proving system behind its [Alpha V5 release](https://aztec.network/alpha-v5). According to the project, an attacker may be able to construct a proof that passes verification for a transaction the network should reject, producing a state transition outside the rules V5 is meant to enforce.

Core contributors identified the flaw on July 27 through internal auditing assisted by artificial-intelligence tooling, after both internal and external human audits had already been completed. Aztec's [disclosure](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) states that funds, applications and contract state on V5 should be treated as exposed to a protocol-level failure until incident response finishes and network operators carry out the required actions, and that contributors cannot determine whether the flaw was exploited before it was found. Reviewers have not identified other critical or high-severity issues in V5.

This is the second proving-system failure in Aztec's alpha sequence. The project disclosed a critical V4 proving vulnerability in March and withheld the technical details until V5 shipped, following a policy of holding back specifics until users can move their funds. That policy trades short-term user awareness for reduced attacker advantage, and reasonable people disagree about the balance. Aztec has raised its bug bounty to $2 million.

The type of bug matters beyond Aztec itself. A soundness defect is not a smart-contract bug and cannot be caught by other nodes re-executing the transaction, because in a proof-based system there is nothing to re-execute against. The question of what exactly a proof binds is being worked out in public elsewhere: a recent [Ethereum Research post on proof boundaries](https://ethresear.ch/t/proof-boundaries-in-a-minimal-homomorphic-tally-for-token-weighted-voting/25831</source_url>") argues that the hard part of a homomorphic tally is not adding encrypted ballots but specifying precisely what the proof must commit to for the sum to represent an election rather than an arbitrary valid computation. The same gap, between a proof that verifies and a proof that means what its designers intended, is what Aztec found in its own system.

## What this means

Rollups and privacy networks that replace re-execution with proofs concentrate their entire security assumption into the proving stack, so a soundness bug there is unbounded rather than contained to one contract. Users of proof-based privacy networks are exposed through a channel they cannot monitor, because a valid-looking proof leaves no on-chain trace of the violation. The practical consequence is slower, more conditional adoption of confidential execution by institutions, and more weight on escape hatches, staged rollouts and proof-system diversity as the criteria buyers apply before committing balances.

## What to watch

- Whether Aztec publishes the technical details of the V5 flaw after operators complete the required network actions, which would let other proving teams check for the same pattern.
- Whether artificial-intelligence-assisted auditing keeps finding critical defects that completed human audits missed, since that would change how much assurance an audit report is worth.
- Whether other zero-knowledge rollups adopt embargoed disclosure timed to upgrades, which decides how much warning users get in future incidents.