Morning Edition · Sunday, August 23, 2026Published at 1:46 AM EDT · New York
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.

Aztec, the privacy-focused Ethereum layer-2 network, has disclosed a critical 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 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, 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 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.
Part of a tracked trend
Proving-System Bugs Become a Distinct Rollup Risk
Soundness defects in zero-knowledge proving systems will keep surfacing as a risk class separate from smart-contract exploits, because validator re-execution — the fallback most rollups rely on — cannot catch them, forcing teams into embargoed disclosure timed to upgrades and pushing users toward proof-system diversity and escape hatches.
Start a discussion in Townsquare.
More from this edition
Aztec gains from a narrative in which its own machine-assisted audit caught a critical flaw before any attacker did, and transparent-execution rollups gain from the implied contrast with privacy chains that have no re-execution fallback.
Every load-bearing detail comes from Aztec's own disclosure, with no third party confirming that the flaw is exploitable, that no funds were taken, or that the V4 disclosure earlier this year was fully remediated, and the project itself notes V5 is Alpha software where such findings are expected.
An open-source-intelligence read of how likely this story is true with its real nuance, not a judgment of any outlet. It assesses the claim, weighing independent and adversarial reporting. How we label confidence.
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
Observations to monitor, not financial advice.
Synthesized from: Aztec Network (vulnerability disclosure) · Aztec Network (Alpha V5) · Aztec Network (applications)
Comments
0No comments yet.