# Aztec Says a Defect in Its Alpha V5 Proving System Could Let an Attacker Forge a Valid Proof

Contributors to the privacy network found the flaw through internal artificial-intelligence-assisted auditing and told users to treat funds and applications on V5 as exposed until operators complete the required network actions.

- Published: 2026-08-16T05:37:57.333Z
- Canonical: https://polylog.news/crypto/2026-08-16/aztec-says-a-defect-in-its-alpha-v5-proving-system-could-let
- 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 (gas on Aztec)](https://aztec.network/blog/how-gas-works-on-aztec)

Aztec, the privacy-focused layer-2 network built on Ethereum, has [disclosed a critical vulnerability in the proving system behind its Alpha V5 release](https://aztec.network/blog/alpha-v5-proving-system-vulnerability). According to the disclosure, an attacker may be able to construct a proof that passes verification for a transaction the network should reject. If the network accepted such a proof, it would produce a state transition outside the rules V5 is written to enforce. Contributors identified the defect on 27 July through internal auditing assisted by artificial-intelligence tooling, after both internal and external human audits had already been completed.

The distinction matters. Most exploits this desk covers are application bugs, where a contract does the wrong thing with the right inputs. A proving-system defect is a soundness failure at the base layer: the component that decides what is true accepts something false. On a transparent rollup, node operators can re-execute transactions and notice a divergence. On a network built to hide transaction contents, that fallback is weaker, because the data needed to re-execute independently is exactly the data the design conceals. That is why Aztec is telling holders to treat funds, applications and contract state on V5 as exposed to a protocol-level failure rather than an application-level one.

This is the second such disclosure in the same code lineage. Aztec [disclosed a critical vulnerability affecting the Alpha V4 proving system in March](https://aztec.network/alpha-v5) and told V4 users to withdraw before a governance vote made the details visible, saying at the time that exploitation could lead to theft of user funds. Two consecutive proving systems shipping with soundness defects, both caught by review rather than by an attacker, is the clearest sign yet that the industry's verification tools have not caught up with the amount of capital now running through them.

The financial exposure here is small in absolute terms. Aztec does not appear among the ten largest layer-2 networks by value secured, a group that holds most of the [$39.27 billion](https://aztec.network/blog/how-gas-works-on-aztec) tracked across Ethereum rollups, led by Base at $11.43 billion and Arbitrum One at $10.09 billion. The larger risk is not Aztec's balance sheet. It is that every rollup relying on a single proving system carries the same class of failure, and that the tooling now finding these bugs first is automated review, not attackers.

## What this means

Proof soundness is the single assumption every zero-knowledge rollup asks users to accept, and it cannot be checked by the ordinary defense of re-running transactions on a privacy chain. Holders of assets on any single-prover rollup are exposed through the same channel: if a proof system accepts an invalid state transition, withdrawals to Ethereum can be drained before anyone reconstructs what happened. The competitive consequence is that networks with multiple independent provers, working escape routes to the base layer, or conservative upgrade governance can now claim a concrete safety advantage over faster single-prover designs, and institutional investors evaluating confidential settlement will weigh that difference.

## What to watch

- Whether Aztec publishes the technical root cause and a fixed release, and whether any other network using related proving code issues its own advisory, which would show the defect class is shared rather than specific to one team.
- Whether other rollups respond by adding a second, independently written prover, the standard fix for this failure mode and an expensive one that shows which teams treat soundness as a budget priority.
- Whether automated auditing keeps finding critical defects that human audits missed, because that would change how quickly teams can honestly claim a system is ready for user funds.
