exploit
Aztec Connect's deprecated RollupProcessorV3 drained for $2.19M via ZK proof boundary mismatch
On June 14, an attacker exploited a numRealTxs vs decoded_slots gap in Aztec Connect's immutable rollup contract and drained 909 ETH, 270,513 DAI and 167.89 wstETH.
An attacker drained roughly $2.19M from Aztec Connect's deprecated RollupProcessorV3 contract on Ethereum around 12:26 UTC on June 14, 2026 by crafting a settlement payload that exposed a boundary mismatch between the contract's numRealTxs loop bound and the decoded_slots set committed inside the ZK proof. The product was shut down in March 2023 and its admin keys renounced, so the bug is unfixable — the contract stays callable until its reserves go to zero. The on-chain trail was first surfaced by BlockSec's Phalcon monitoring; SlowMist published the root-cause analysis on Medium, and the Aztec Foundation confirmed on X that the affected code has no link to the current Aztec network, Aztec Labs' new rollup or the AZTEC ERC-20 token.
What happened
RollupProcessorV3 was the L1 settlement contract for the original Aztec Connect privacy product — a Turbo-PLONK ZK-rollup that batched DeFi calls on behalf of Ethereum users. Aztec Labs deprecated Connect on March 21, 2023 and renounced the admin and upgrade roles a few weeks later. The pool sat with leftover liquidity that nobody bothered to migrate, because the rollup verifier was assumed to bind every public input slot it accepted.
It didn't. The contract's settlement loop iterated over the first numRealTxs slots of the rollup block, decoded them as deposits/withdrawals, and updated the L1 token balances accordingly. The accompanying PLONK proof, however, committed via SHA-256 to the full decoded_slots array — a larger set. Any slot between numRealTxs and decoded_slots.length was constrained by the ZK circuit but never visited by L1 settlement. The attacker placed legitimate deposit instructions in those out-of-range slots, kept numRealTxs artificially low, and routed the withdrawals through an intermediary contract. The L2 state credited the deposits; L1 never debited the pool.
A single atomic transaction at block 25,315,715 withdrew the entire residual reserve.
On-chain trail
- Attacker EOA:
0x0F18D8b44a740272f0be4d08338d2b165b7EdD17. Funds were swept from the deprecatedRollupProcessorto this address via an intermediary attack contract (prefix0x06f585…d0fcD). - Block height: 25,315,715, mined ~12:26 UTC on June 14.
- First public flag: BlockSec's Phalcon Block monitoring, before any team statement.
- Aztec Foundation statement on X, posted later that day: confirms the exploit hit Aztec Connect (deprecated since March 2023), and confirms no link to the AZTEC ERC-20 token or to any contract in the current Aztec rollup.
- Technical analysis: SlowMist on Medium, naming the
numRealTxs/decoded_slotsmismatch as the root cause.
Mechanism — settlement boundary vs ZK proof commitment
The conceptual error is general enough that it's worth restating in plain terms:
- The ZK circuit constrains every public input slot the prover commits to. The circuit said "the full
decoded_slotsarray is well-formed." - The L1 contract trusts that constraint, but only iterates
numRealTxsslots when applying balance changes. - If
numRealTxs < decoded_slots.length, there are slots whose data the circuit checked but the L1 never read. The attacker put valid-looking deposit slots in that gap. - L2 accounting (in the circuit's view) treated all slots as real. L1 accounting (in the contract's view) only debited the first
numRealTxs. The pool over-credits the L2; the L2 withdraws against that credit; the L1 has no debit to balance it.
SlowMist's takeaway: L1 must independently verify every public-input slot the ZK proof commits to. A boundary parameter cannot be trusted just because the proof passes.
Numbers
- Total drained : ~$2.19M
ETH : 908.99 ETH (~$1.6M at event)
DAI : 270,513 DAI
wstETH : 167.89 wstETH (~$357K at event)
- Block : 25,315,715 (~12:26 UTC, Jun 14, 2026)
- Contract : RollupProcessorV3 (Aztec Connect, deprecated Mar 2023)
- Admin keys : renounced — contract is immutable, no patch path
- Detected by : BlockSec Phalcon
- Analyzed by : SlowMist, CertiK
- Current Aztec network : not affected (separate codebase)
- AZTEC ERC-20 token : not affected (unrelated contract)
USD valuations are at-event per SlowMist's breakdown; the token unit figures come from the attacker's outflow ledger.
Impact
- Aztec Connect users: nobody had been actively using Connect since the 2023 shutdown. The drained pool was leftover liquidity from users who never withdrew. The loss is real but borne by a long-dormant cohort.
- Aztec Labs and the current Aztec network: explicitly unaffected. Aztec Labs has been building a new rollup since 2023; the verifier and contracts there are unrelated.
- The AZTEC ERC-20: unrelated contract, no exposure.
- Other long-deprecated ZK-rollups still holding L1 reserves: this is the alarm. Any rollup whose admin keys were renounced and whose verifier accepted a
numTxs-style loop bound separate from the proof's public-input commitment should be re-audited. The class of bug is structural, not specific to Aztec's circuit.
What to watch
- Any further outflows from
0x0F18…dD17. With admin keys renounced, the only mitigation lever is exchange-side freezes if the funds touch a CEX. Track Tornado Cash deposits and CEX deposit transactions referencing the address. - SlowMist's follow-up on whether other deprecated rollup contracts share the
numRealTxs/decoded_slotsshape. If they do, copycat drains are a one-PR-read away. - Aztec Foundation / Aztec Labs statement on remaining Connect reserves, if any survive the drain. The pool is contractually unrecoverable but the team can still publish an inventory.
- CertiK and other auditors publishing retroactive write-ups of their original Connect audits, if any of them flagged or missed the loop-bound vs public-input gap. The forensics matter for how the wider audit industry recalibrates ZK reviews.
Context — deprecated does not mean off
This is the second time in a week that a contract everyone had stopped looking at took the loss. Raydium lost $1.34M on June 10 when a five-year-old AMM V3 program — long retired from its frontend — got drained because it never validated the LP mint against the pool (Blockchain Posts coverage). The Raydium pattern was a missing input-mint check on Solana; the Aztec pattern is a missing public-input bounds check on Ethereum. Different chains, different primitives, same lesson: an on-chain program is live until its authority is migrated, revoked or its reserves drained — whichever happens first. Renouncing admin keys does not retire a contract. It just guarantees that whoever finds the next bug keeps the proceeds.
Sources:
- SlowMist (Medium) — Analysis of the $2.19 Million Asset Theft from Aztec Connect: ZK-Rollup Settlement Boundary Bypass Leads to L1/L2 State Discrepancy (primary technical post-mortem).
- Aztec Foundation on X — "The Aztec Foundation was made aware of a potential exploit targeting Aztec Connect…" (primary statement).
- The Defiant — Aztec Connect Drained of $2.1M Through Deprecated Contract Three Years After Shutdown.
- crypto.news — Aztec Connect loses $2.1m after old contract exploit.
- NewsBTC — Legacy Aztec Connect Contract Drained Of $2.1 Million Three Years After Shutdown.
- Cryptopolitan — Aztec Labs draws line with deprecated Aztec Connect product after $2.1M exploit.
- On-chain entry point: attacker EOA
0x0F18…dD17(Etherscan).