# Aztec Discloses a Critical Flaw in the Proving System Securing Its Live Privacy Network

Core contributors say an attacker could construct a proof that verifies for a transaction the network should reject, six days after Alpha V5 went live on mainnet.

- Published: 2026-08-23T05:46:20.809Z
- Canonical: https://polylog.news/crypto/2026-08-23/aztec-discloses-a-critical-flaw-in-the-proving-system-securi
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network (vulnerability disclosure)](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network (Alpha V5)](https://aztec.network/alpha-v5), [Aztec Network (applications)](https://aztec.network/blog/dark-forest-aztec-game-goes-live)

Aztec, the privacy-focused Ethereum layer-2 network, has [disclosed a critical vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) in the proving system of its Alpha V5 release. Core contributors identified the flaw on 27 July 2026 through internal auditing assisted by machine analysis. The description is specific and severe: 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 the protocol intends to enforce. Contributors told users to treat funds, applications, and contract state on V5 as exposed to a protocol-level failure until incident response completes and node operators carry out the required network actions.

The finding comes days after [Alpha V5 launched on mainnet](https://aztec.network/alpha-v5) on 21 July, a release that cut fees below five cents and proved a private transaction in about 2.5 seconds on a consumer laptop. It is also the second proving-system failure in the same lineage. Aztec disclosed a critical vulnerability in Alpha V4 earlier this year and, according to [The Defiant](https://thedefiant.io/news/defi/aztec-v4-withdraw-june-25-v5-upgrade-security-vulnerability), told V4 users to withdraw before 25 June, when a governance vote would make the V4 flaw public.

A soundness bug in a zero-knowledge proving system is a different risk class from a smart-contract bug. Most rollups rely on validators re-executing transactions to catch an invalid state root. On a network where execution is private by construction, that mechanism does not exist, because no one outside the transaction can re-run it. The proof is the only verification that distinguishes a valid ledger from a forged one.

Aztec has continued releasing new features in parallel, including an on-chain game [now running on the network](https://aztec.network/blog/dark-forest-aztec-game-goes-live) and published documentation on its fee mechanism. That combination, a live network with real applications alongside an acknowledged proof-verification defect, illustrates the pattern the privacy sector is likely to repeat as it moves from testnets to production.

## What this means

The exposure sits with anyone holding assets or contract state on Aztec's V5 network, and the channel is a forged state transition rather than a stolen key. More broadly, every rollup that markets itself on proof validity now has to answer whether its own verifier has been reviewed to the same depth as its contracts, and privacy chains carry the sharper version of that question because they have no re-execution fallback to catch the error. Either the sector converges on multiple independent proof implementations and working contingency mechanisms, or repeat disclosures of this kind keep institutional capital in transparent execution environments.

## What to watch

- Whether Aztec publishes the technical detail of the flaw and the operator actions it required, which will show whether the fix is a circuit correction or a broader redesign.
- Whether other zero-knowledge rollups adopt multiple independent proof systems, the standard practical defence against a single verifier being wrong.
- Whether machine-assisted auditing keeps finding these defects before attackers do, which would change the disclosure pattern from post-loss to pre-loss.
