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

Aztec, the privacy-focused Ethereum layer-2 network, has disclosed a critical flaw in the proving system of its Alpha V5 network. Core contributors found the defect on July 27 through internal AI-assisted auditing, Aztec said. 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 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, 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. 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 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.