# Aztec Says Its Alpha V5 Proving System Could Accept Invalid Transactions, and It Cannot Tell Whether Anyone Exploited the Flaw

The fix is scheduled for V6, while Aztec has separately set the end of 2030 as its target for moving the privacy network to post-quantum cryptography.

- Published: 2026-10-23T05:49:02.326Z
- Canonical: https://polylog.news/crypto/2026-10-23/aztec-says-its-alpha-v5-proving-system-could-accept-invalid
- 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/post-quantum-aztec), [Ethereum Research](https://ethresear.ch/t/paranoid-eip-8288-heterogeneous-recursion-with-an-authenticated-class-bank/26170), [The Defiant](https://thedefiant.io/news/blockchains/aztec-targets-full-post-quantum-migration-by-end-of-2030)

Aztec, the privacy-focused Ethereum layer-2 network, has disclosed a critical flaw in the proving system of its [Alpha V5](https://aztec.network/alpha-v5) network. Core contributors found the defect on July 27 through internal AI-assisted auditing, [Aztec said](https://aztec.network/blog/alpha-v5-proving-system-vulnerability). The flaw is a soundness bug. An attacker could build a proof that passes verification for a transaction the network should reject. That transaction could then change state in ways the V5 rules forbid.

Aztec said the flaw puts V5 funds, applications and contract state at risk. It also said it cannot determine whether anyone used the flaw before the team found it. The system does not record enough information to separate ordinary transactions from transactions accepted through the faulty proving path. As a result, the chain's history cannot show whether exploitation happened or how much it cost. The fix is planned for V6. Reviewers have found no other high-severity or critical V5 defects. Aztec notes that V5 is still Alpha software, the stage meant for finding faults before production. The team [reported a separate critical flaw in Alpha v4](https://aztec.network/blog/critical-vulnerability-in-alpha-v4) earlier.

The private design limits the fallbacks available. A public rollup can let validators re-execute transactions to check a proof. A privacy network hides transaction inputs, so the proof is the main check that execution followed the rules. A sound-looking proof over a false statement leaves no other record to inspect.

Aztec also published a [post-quantum roadmap](https://aztec.network/blog/post-quantum-aztec), written by co-founders Zac Williamson and Mike Connor, that targets full migration by the end of 2030. The schedule calls for hardened developer libraries in February 2027. New signature schemes would be selected in March 2027, public-key encryption in July 2027 and zero-knowledge proof systems in November 2027, [The Defiant reported](https://thedefiant.io/news/blockchains/aztec-targets-full-post-quantum-migration-by-end-of-2030). A complete migration also depends on changes to Ethereum's data-availability layer.

Ethereum researchers are working on the same question at the base layer. A post on [Ethereum Research](https://ethresear.ch/t/paranoid-eip-8288-heterogeneous-recursion-with-an-authenticated-class-bank/26170) examines Ethereum Improvement Proposal (EIP) 8288, which would aggregate proofs recursively under one fixed verification key set by the protocol. The author tests a deliberately cautious design, described as "paranoid," that allows only a short list of approved proof sizes.

## What this means

When a soundness bug sits in a privacy system, the loss may be impossible to measure, and that removes the forensic accounting users rely on after a smart-contract exploit. Anyone holding value on Aztec is exposed, as is any future design that relies on one proving system, including the protocol-level aggregation that EIP-8288 explores. The precedent is Zcash. In 2018 its engineers found a counterfeiting flaw in the original Sprout proving parameters, fixed it quietly in the Sapling upgrade and disclosed it in 2019. They could never prove the flaw went unused and relied on pool-boundary supply accounting (the "turnstile") to limit the risk. Aztec's statement does not describe a comparable supply check. Aztec wants an institutional privacy audience, and that audience will ask for exactly that kind of bound before committing capital. The quantum roadmap adds a second timing risk. Encrypted notes posted publicly today could be read later if their encryption scheme falls. The likelier outcome is that V6 ships with supply-boundary accounting and a second or upgraded proving path before Aztec invites meaningful value, which would push its production timeline out by months. That depends on Aztec treating this disclosure as a design requirement rather than a patch. The forward read is wrong if V6 launches with one proving system and no mechanism to bound counterfeit supply.

## What to watch

- Whether Aztec's V6 specification adds a way to bound total supply, which would turn an unknowable loss into a measurable one.
- Further critical findings from AI-assisted audits of other zero-knowledge rollups. More cases would show whether the same tooling is surfacing proving bugs across the sector.
- How Ethereum researchers settle the EIP-8288 design, because a single protocol-level verification key would turn one proving-system bug into a base-layer risk.