# Aztec Discloses an Alpha V5 Flaw That Could Let an Invalid Transaction Pass Proof Verification

Core contributors found the defect through internal AI-assisted auditing, say the chain's history cannot show whether anyone exploited it, and are deferring the fix to V6 while urging teams to pause V5 deployments.

- Published: 2026-10-01T05:49:51.228Z
- Canonical: https://polylog.news/crypto/2026-10-01/aztec-discloses-an-alpha-v5-flaw-that-could-let-an-invalid-t
- 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 Network (blog)](https://aztec.network/blog/dark-forest-aztec-game-goes-live)

Aztec, the privacy-focused Ethereum layer-2 network, disclosed a [critical vulnerability in the proving system behind its Alpha V5 release](https://aztec.network/blog/alpha-v5-proving-system-vulnerability). According to the project, an attacker could construct a proof that passes verification for a transaction the network should reject, producing a state transition outside the rules Alpha V5 is meant to enforce.

Two details make this a soundness problem rather than an ordinary bug. First, the project says it cannot determine whether anyone exploited the flaw, because the affected system does not log enough information to distinguish ordinary accepted transactions from transactions accepted through the defective proving path. Historical chain data cannot settle the question or measure the impact. Second, contributors say they found the defect through internal AI-assisted auditing and are shipping the fix in V6 rather than patching V5. They are advising teams planning a V5 deployment to pause, and teams with live contracts on the [Alpha V5 network](https://aztec.network/alpha-v5) to review how they would isolate affected functionality and migrate users to new deployments.

This is the second critical finding in Aztec's alpha testing cycle, after the V4 disclosure that led users to withdraw ahead of the [V5 upgrade](https://thedefiant.io/news/defi/aztec-v4-withdraw-june-25-v5-upgrade-security-vulnerability). The project describes both findings as the intended result of alpha testing on a network it deliberately labels pre-production, and it has [raised its bug bounty to 2 million dollars](https://aztec.network/blog/aztec-network-raises-total-bug-bounty-to-2-million). Application teams building on the network, including the consumer and game deployments Aztec has promoted, such as the [on-chain game Dark Forest](https://aztec.network/blog/dark-forest-aztec-game-goes-live), now face a migration cost they did not plan for.

Proof-system defects differ from contract exploits in one respect that matters for every rollup, not just this one. An optimistic system lets honest parties re-execute transactions and challenge a bad result. A validity-proof system instead treats the verifier as the final authority. If the verifier accepts a false statement, there is no second check, and a chain that does not log which proving path accepted a transaction cannot audit itself afterward.

## What this means

The mechanism is a verifier that can be made to accept a false statement, and the parties exposed are the application teams and users holding balances on a privacy chain where forensic review after the fact is limited by design. Aztec gains credibility for disclosing the flaw and for finding it itself, but loses deployment momentum, because the advice to pause V5 integrations delays the pipeline of applications any new layer-2 network needs. The relevant precedent is the pattern among zero-knowledge rollups of disclosing soundness findings in coordination with an upgrade rather than patching immediately, since a change to the verifier touches consensus. The desk's read: Aztec's mainnet timeline slips toward the V6 release, and other zero-knowledge teams respond over the next several months by funding proof-system diversity and building explicit escape hatches, the only defenses that work when the verifier itself is wrong. A disclosure that the flaw was exploited on the live alpha network, or that a similar defect exists in a widely shared proving library, would make this a much larger problem than one project's alpha cycle.

## What to watch

- Whether Aztec publishes technical specifics once V6 ships, because the class of error, whether in circuit constraints or in the verifier, determines how many other projects using the same tooling must re-audit.
- Whether other zero-knowledge rollups announce proof-system redundancy or multi-prover setups, which would mark soundness risk moving from a research concern to a budgeted engineering problem.
- Whether application teams on Aztec migrate or stay, as migration activity shows how much of the privacy network's developer base is willing to absorb in pre-production costs.