# Aztec discloses a proving-system flaw in Alpha V5 that could let invalid transactions pass verification

Contributors found the defect on July 27 through AI-assisted internal auditing. They say they cannot tell whether anyone used it, and that version 6 will reject proofs from the affected system.

- Published: 2026-10-10T05:48:41.996Z
- Canonical: https://polylog.news/crypto/2026-10-10/aztec-discloses-a-proving-system-flaw-in-alpha-v5-that-could
- 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/critical-vulnerability-in-alpha-v4)

Aztec, the privacy-focused Ethereum layer-2 network, has disclosed a [critical vulnerability in the proving system of its Alpha V5 network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability). Core contributors found the flaw on July 27 through internal auditing assisted by artificial intelligence (AI). According to Aztec, an attacker could build a proof that passes verification for a transaction the network should reject. If accepted, that transaction could change the network's state in ways the [V5 rules](https://aztec.network/alpha-v5) are meant to forbid.

This is a soundness defect, meaning the system can accept a false statement as true. It is a different kind of failure from a smart-contract bug. In a contract exploit, the chain runs bad code correctly and the damage is visible on-chain. In a soundness failure, the verifier itself certifies a state change that never followed the rules. Aztec says V5 funds, applications and contract state should be treated as exposed to a protocol-level failure. That holds until contributors finish their incident response and node operators take the required network actions.

The disclosure contains an unusual admission: contributors cannot determine whether anyone used the flaw before they found it. They wrote that the affected system does not record the information needed to separate ordinary accepted transactions from transactions accepted through the flawed proving path. On a privacy network, validators cannot re-execute private transactions, so they cannot check them after the fact. Re-execution is the safety check many rollups rely on, and here it is not available.

This is not Aztec's first such disclosure. The team previously disclosed a [critical vulnerability in Alpha V4](https://aztec.network/blog/critical-vulnerability-in-alpha-v4). Aztec says the V5 findings will shape the V6 release, including circuit updates that stop the network from accepting proofs tied to an affected proving system. More than two months passed between the July finding and the public write-up. That gap fits a pattern of embargoed disclosure timed to upgrades.

## What this means

On a private zero-knowledge network, the proof is the only thing checking each transaction. A soundness bug therefore exposes every balance, and it does so in a way outsiders cannot audit afterward. The parties exposed are users and applications on Aztec's alpha. More broadly, the case weakens the argument that privacy layer-2 networks are ready to hold institutional capital. The closest precedent is Zcash's 2018–2019 counterfeiting vulnerability. That bug also allowed undetectable creation of value, and it was disclosed only after an upgrade retired the affected parameters. Zcash's answer was supply accounting at the boundary between shielded pools, so no pool could withdraw more than had been deposited. The desk's read is that V6 will most likely ship with the promised circuit changes within months. Large users will then ask privacy networks for bounded-exposure designs before they commit capital, such as caps on deposits, pool-level supply checks and multiple independent proof systems. That read is wrong if V6 slips well past the team's own schedule, or if another soundness defect surfaces in the next release.

## What to watch

- Whether Aztec's V6 adds supply checks that can show, after the fact, that no value was created through the flawed path. Without them, the question of whether the bug was used stays open permanently.
- Whether other zero-knowledge rollups publish similar AI-assisted audit findings. If they do, proving-system bugs become a recurring risk category in its own right.
- Deposit caps or withdrawal limits on Aztec's network after the disclosure. These show how much exposure the team is willing to carry while the proof system matures.
