# Aztec Discloses Proving-System Defect That Could Let Invalid Transactions Pass Verification

Core contributors found the flaw through internal artificial-intelligence-assisted auditing and say funds, applications and contract state on Alpha V5 should be treated as exposed until the fix ships in V6.

- Published: 2026-09-23T11:09:57.416Z
- Canonical: https://polylog.news/crypto/2026-09-23/aztec-discloses-proving-system-defect-that-could-let-invalid
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [Aztec Network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), [Aztec Network (Alpha V5)](https://aztec.network/alpha-v5), [Aztec Network (gas model)](https://aztec.network/blog/how-gas-works-on-aztec), [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 in the proving system behind its Alpha V5 network](https://aztec.network/blog/alpha-v5-proving-system-vulnerability). According to the project's core contributors, an attacker may be able to construct a proof that passes verification for a transaction the network should reject. Contributors say the finding places funds, applications and contract state on [Alpha V5](https://aztec.network/alpha-v5) at risk of a protocol-level failure until incident response finishes and network operators carry out the required actions, with the correction planned for V6.

This is a soundness defect, not a smart-contract bug. In a zero-knowledge system, the verifier accepts a short proof in place of re-executing the underlying computation, so if the proof system can be made to accept an invalid statement, every guarantee built above it fails at once. Validator re-execution, the fallback most rollups rely on, does not catch this class of error, because the network never re-runs the computation in the first place.

The disclosure follows the same pattern Aztec used for a critical vulnerability in Alpha V4, where the project urged users to withdraw funds before the flaw was publicly described alongside the V5 upgrade. Withholding disclosure of a soundness bug until a replacement network is ready protects users while the flaw is open, but it also means the public record of a network's security lags behind the network itself.

Contributors say internal and external human audits had already been completed and that the defect surfaced through artificial-intelligence-assisted review that continues alongside human work. That cuts against the argument that advancing model capability is purely a threat to cryptographic systems.

Aztec has been building out the surrounding stack in parallel, publishing an explanation of [how gas and fees work on the network](https://aztec.network/blog/how-gas-works-on-aztec) and pointing to [applications going live](https://aztec.network/blog/dark-forest-aztec-game-goes-live). This disclosure measures the distance between an alpha network carrying real balances and a network whose proof system has been shown, in theory, to be defeatable.

## What this means

Every rollup that replaces execution with a proof inherits the proof system as its trust base, and a soundness bug there cannot be caught by watching the chain. Users of privacy networks are the most exposed, because confidential state makes it harder to see whether an invalid transaction has already been accepted. The counterweight is that Aztec found this in an alpha network with disclosed exposure rather than on a mainnet holding institutional balances, which is the argument for shipping privacy systems through long staged rollouts instead of straight to production.

## What to watch

- Whether Aztec publishes the technical root cause after the V6 migration, since a specific description lets other teams check whether their own circuits or verifiers share the pattern.
- Whether other zero-knowledge layer-2 networks add escape hatches or second proof systems, the practical answer to a verifier that can be tricked.
- How much value stays on Alpha V5 through the disclosure window, which shows whether users treat a stated protocol-level risk as actionable.