# Aztec Says a Flaw in Its Alpha v5 Proving System Could Have Let a False Proof Pass Verification

Core contributors found the soundness bug through internal AI-assisted auditing on 27 July and are deferring the fix to the next release, the second critical proving-system defect Aztec has disclosed this year.

- Published: 2026-08-31T05:50:12.747Z
- Canonical: https://polylog.news/crypto/2026-08-31/aztec-says-a-flaw-in-its-alpha-v5-proving-system-could-have
- 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](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) in the proving system behind its Alpha v5 release. According to the team, an attacker could construct a proof that passes verification for a transaction the network should have rejected. Core contributors identified the defect on 27 July through internal auditing assisted by automated code analysis, and the repair is scheduled for the next version rather than a patch to the running network.

This is a different class of failure from a smart-contract bug. In a zero-knowledge system, the proof is the only thing a verifier checks. If the proving circuit is unsound, the verifier accepts a false claim, and every downstream assumption about balances and ownership fails at once. Validator re-execution, the fallback that catches ordinary execution errors on optimistic systems, does not detect it, because the network never sees the underlying computation.

The disclosure follows the same pattern Aztec used in March, when it announced a critical vulnerability in Alpha v4 and shipped the fix inside the [v5 release](https://aztec.network/alpha-v5). Aztec has raised its bug bounty to $2 million and says reviewers have not identified other high-severity findings in v5 at this time. The network remains an alpha deployment, which is why the team can hold a soundness defect for a scheduled upgrade rather than trigger an emergency response.

The straightforward reading is that repeated findings in a maturing prover are what alpha testing is for. The harder one is that these bugs are being found by the team that wrote the code, and that no independent party has demonstrated it can find them first.

## What this means

Every rollup that replaces re-execution with a single proving system inherits the same concentrated risk, and the people exposed are users whose withdrawals depend on one verifier contract. As tokenized assets and private stablecoins move onto proof-based chains, the operational question shifts from whether contracts are audited to whether anyone outside the core team can independently falsify a proof. Two outcomes divide here: either proof-system diversity and escape hatches become standard before real value arrives, or the first soundness bug found by an attacker rather than an auditor lands on a network holding institutional balances.

## What to watch

- Whether Aztec's v6 release ships the fix on schedule and whether an outside auditor, not the core team, confirms it.
- Whether other zero-knowledge rollups adopt multiple independent provers or a delay window that gives users time to exit if a proof is disputed.
- How much value accumulates on proof-based privacy networks before independent verification tooling exists, since the gap between the two is where the loss would land.