Crypto Card News

Payy Post-Mortem Blames Noir Verifier Flaw for $1.9M Bridge Loss

Published: Sep 30, 2026•By Aleksandar Dukic

Key Analysis

Payy's post-mortem pins its September 24 bridge exploit on a flaw in Aztec's Noir/Barretenberg verifier that accepted an invalid burn proof, draining ~1.92M USDC.

Payy Post-Mortem Blames Noir Verifier Flaw for $1.9M Bridge Loss

Listen To This Article

Payy Post-Mortem Blames Noir Verifier Flaw for $1.9M Bridge Loss

3m 30s audio

AI narration. Useful for scanning on the move. Names and tickers may be mispronounced.

Payy has published a technical post-mortem for the September 24, 2026 exploit of its bridge contract, and the conclusion points away from stolen keys and toward the cryptography itself. According to the official account, an attacker submitted an invalid burn proof that Payy's deployed Noir and Barretenberg verifier accepted as valid. Two transactions moved roughly 1.92 million USDC out of the Payy rollup to a single receiving wallet.

The finding matters for anyone who funds a Payy card or holds a balance on the network, because the failure was not in how funds were stored. It was in the checkpoint that decides whether a withdrawal is legitimate.

The two burns that drained the bridge

The first burn released 1,828,589.378132 USDC from the Payy rollup even though the underlying transaction appears to have been invalid. A second burn of 1 USDC was paid early by a burn substitutor and later reimbursed, and that second transaction released a further 90,202.820016 USDC to the same wallet. Combined, the attacker extracted close to 1.92 million USDC.

Payy's earlier statement had already ruled out a private-key compromise and social engineering. This post-mortem closes the loop on what actually broke: a proving-system vulnerability in the Noir/Barretenberg verifier, which is developed by Aztec rather than by Payy itself.

A shared dependency, not a Payy-only bug

The distinction is important. Payy uses zero-knowledge proofs to keep spending private while still proving that funds exist and have not been double-spent. The verifier is the on-chain code that checks those proofs before releasing money. When it accepts a proof it should have rejected, the whole security model of the bridge collapses at that single point.

Because the flawed component sits in Aztec's toolchain, the concern extends past one card issuer. Any project relying on the same verifier code path inherits the same risk until it is patched. That is the second-order story here: this is a supply-side flaw in widely used ZK tooling, closer in shape to the Chainlink cross-chain bridge incident than to a garden-variety smart-contract bug in a single app.

Cardholder guidance until the verifier is fixed

For cardholders, the practical questions are whether balances were touched and whether the bridge is safe to use again. The attacker's withdrawals came out of the rollup's pooled liquidity rather than by forging individual account balances, and Payy has not reported that user funds beyond the drained amount were reassigned. Still, the responsible move until the verifier is confirmed fixed is to keep bridge exposure small and avoid parking large sums on the network.

This is also a reminder about custody framing. A self-custody wallet protects you from an issuer running off with your keys, but it does not protect you from a validity bug in the code that guards the exit. The private key stayed safe here; the proof check did not.

Payy says a full report accompanies the post-mortem. The next thing to look for is a confirmed patch to the verifier, an independent audit of the fix, and any restitution plan for the drained liquidity. Until those land, treat the bridge as under repair.

Overview

Payy's September 24 bridge exploit stemmed from its Noir/Barretenberg verifier accepting an invalid burn proof, draining roughly 1.92 million USDC across two transactions to one wallet. The root cause is a proving-system flaw in Aztec's tooling, not a key leak, which widens the risk to any project using the same verifier. Cardholders should minimize bridge exposure until a patched verifier and an audited fix are confirmed.

DisclaimerThis article is provided for informational purposes only and does not constitute financial advice. All fee, limit, and reward data is based on issuer-published documentation as of the date of verification.

Have a question or update?

Discuss this analysis with the community on X.

Discuss on X

Comments

Comments are moderated and may take a moment to appear.