$2.19M Drained on Aztec: How Blockaid Flagged an Exploit Before It Happened

Executive Summary

On June 14, 2026, an attacker drained approximately $2.19M from the deprecated Aztec Connect rollup contracts on Ethereum in a single transaction. Working from a freshly funded, Tornado Cash-sourced, wallet, the attacker deployed a set of helper contracts and exploited a settlement-boundary flaw to mint balances backed by no real deposits, then withdrew them. The attack used neither a stolen key nor a break in the proof system.

Blockaid's Onchain Monitoring platform detected the attacker's preparation onchain six minutes before the exploit transaction, identifying the setup step as it happened, well before the funds were drained. Blockaid issued advisories warning ecosystem participants not to interact with the contract while the attack was still unfolding. Aztec Labs later credited Blockaid for flagging the pre-transaction step.

Blockaid's automated detection sees exploits forming onchain in real time, before they execute, in the narrow window where a developing attack can still be acted on. For protocols and institutions with assets onchain, that early visibility is the difference between watching a drain in a block explorer after the fact and getting a warning while there is still time to respond. This particular attack hit a deprecated, unmaintained contract, part of a broader trend in which attackers are now exploiting.

Background: zk-Rollups, Proof Verification, and Settlement Accounting

Aztec Connect was a privacy-preserving zk-rollup on Ethereum, launched in 2022 and deprecated in 2023. It lets users shield assets and interact privately with DeFi protocols such as Lido and Yearn by batching many user transactions into a single Ethereum settlement, with correctness guaranteed by a zero-knowledge validity proof. 

In April 2024, after a year of notice urging users to withdraw, Aztec Labs formally and permanently renounced all administrative roles and upgrade authority onchain, so that users could continue exiting without any input from Aztec Labs. As Aztec Labs has stated, it holds no control over these contracts. The live Aztec Network and its present-day systems are entirely separate and were not affected.

A zk-rollup like Aztec Connect splits responsibility between two subsystems that have to agree with each other. The validity proof guarantees that a batch of transactions is internally consistent, so that balances reconcile, nothing is created from nothing, and the new state follows correctly from the old. The onchain settlement code, the Ethereum contract itself, is what actually moves real assets in and out based on that batch. These two layers read the same batch, and the exploit lived in a place where they read it differently. The proof validated one view of the batch while the settlement code acted on another, and that gap is what let the attacker create balances the contract never collected real deposits for.

The Exploit: How It Unfolded

1. The Attacker's Setup

The attacker funded a fresh Ethereum wallet, 0x0F18D8b44a740272f0be4d08338d2b165b7EdD17, through Tornado Cash, then deployed a sequence of helper contracts in the minutes before the attack. The final helper contract, 0x06f585F74e0DA633Ae813A0f23Fb9900B61d0fcD, was the one used to execute the drain. This entire preparation sequence ran from roughly 12:16 to 12:20 UTC, ahead of the draining transaction at 12:26 UTC.

This setup phase is exactly where Blockaid's Onchain Monitoring caught the attack. The platform's pre-exploit simulation flagged the preparation activity as anomalous and automatically paged Blockaid's team, with the wallet's Tornado Cash funding among the signals marking it as high-risk. That detection fired on the setup step rather than the drain itself, roughly six minutes before the exploit transaction landed, which is what opened the window to alert the ecosystem while the attack was still forming.

2. The First Attack: A Settlement-Boundary Flaw

Each Aztec Connect rollup bundles a batch of individual transactions, and the proof system inspects them in fixed groups of 32. Even when only a few transactions in a group are used, the proof checks and accepts the whole group. The onchain settlement code, however, acts only on the first numRealTxs transactions the batch declares. The proof accepts a whole group of 32, but settlement processes only the count it is told. That mismatch means a transaction can be accepted by the proof yet never processed by the settlement code. The checks that settlement would normally run, including the one ensuring a credited deposit was backed by funds actually sent to the rollup, are simply skipped for any transaction past the declared count. Internal user balances can be updated without legitimate deposits behind them.

3. Minting Unbacked Balance

Through the helper contracts, the attacker made 14 calls to the rollup's settlement function, processRollup (rollupId 13277 through 13290), all inside the single exploit transaction 0x074ec9317d8336db37e8c348fbdd7515573ff4088239c77ab429f522509aeeb1. Each call carried a valid proof and was crafted the same way. The batch declared one real transaction (row 0) while packing two (rows 0 and 1). The proof accepted both rows, while settlement acted only on row 0. In the balance-creating calls, row 0 was a harmless internal transfer that settled normally, while row 1 was a large deposit that the proof credited inside the system but that settlement never collected, because it sat past the declared count. The attacker now held internal balance backed by no real assets.

4. Draining the Pool

In the remaining calls, the attacker placed ordinary withdrawals at row 0, and the contract paid them out in ETH and tokens to the attacker's wallet. Repeated across the 14 batches in a single transaction, this converted the fabricated internal balances into a real drain. The transaction moved approximately 909 ETH, 270,513 DAI, 168 wstETH, 4,874 yvDAI, 17 yvWETH, 9,274 LUSD, and 359 yvLUSD from the Aztec Connect rollup processor proxy, 0xFF1F2B4ADb9dF6FC8eAFecDcbF96A2B351680455, to the attacker, totaling approximately $2.19M at the time of the exploit. Blockaid's analysis of the exploit block found no compensating same-block transfers. The movement was a one-way extraction from the proxy to the attacker.

5. The Second Attack

The same vulnerability was targeted a second time the following day. Beginning around 04:00 UTC on June 15, a second freshly funded wallet submitted 14 further processRollup calls (rollupId 13291 through 13304), picking up exactly where the first attack stopped. This round targeted the residual DeFi bridge positions still held by the rollup, extracting wrapped Aave and Compound tokens, a TroveBridge position, and Euler-wrapped WETH, then redeeming the recoverable wrappers into ETH and DAI outside Aztec Connect. The second attack extracted approximately $88K in residual value. The extracted ETH and DAI from both rounds were funneled through a short chain of disposable wallets toward a high-volume exchange-like service, a pattern consistent with cashing out through a centralized venue.

The Pre-Execution Detection Window

Blockaid's Onchain Monitoring platform scans ecosystems block-by-block to detect anomalies that can potentially lead to an exploit. In this incident, the platform's pre-exploit simulation automatically flagged the attacker's preparation step roughly six minutes before the draining transaction executed, catching the activity during the setup phase rather than only seeing the exploit once it executed.

Blockaid classified the activity as an exploit rather than a routine transaction and identified the victim contract, the attacker address, and the exploit transaction. The analysis also established early that this was a logic exploit rather than a key or access compromise. There was no sign of admin or proxy key theft, and the proxy implementation was unchanged before and after the attack, which pointed to the settlement-boundary flaw rather than a stolen credential. Blockaid issued advisories through its incident channels warning ecosystem participants to avoid interacting with the contract while the situation was live.

The nature of these contracts shaped what could be done next. Because Aztec Labs had renounced all control in 2024, there was no admin key to pause the contract, no upgrade path to patch the flaw, and no party with authority to freeze the funds. Detection and advisory were the available levers, and Blockaid acted on both. In its own incident disclosure, Aztec Labs credited Blockaid for flagging the pre-transaction setup step and helping accelerate identification of the incident.

Why Onchain Monitoring Matters for Protocols and Institutions

Blockaid detected the attacker's preparation roughly six minutes before the draining transaction executed. On contracts no one could pause, that window did not change the outcome, but on a live protocol or an actively managed onchain position, six minutes is the difference between stopping an exploit and reading about it afterward. That early-warning window is the capability that matters, and it is the reason pre-transaction detection sits at the center of how Blockaid protects onchain assets.

Most onchain risk lives on a surface an organization does not fully control: shared protocols, bridges, and infrastructure that an attacker can target without ever touching the organization's own keys or contracts. Permission models and contract-level checks govern what the organization itself can do, but they do not see a hostile actor assembling an attack from the outside. Onchain Monitoring closes that gap. It continuously scans an ecosystem block-by-block and uses transaction simulation to surface the anomalous preparation and execution patterns that precede a drain, detecting threats earlier than permission-based or contract-level controls can. In this incident, that meant flagging the attacker's setup step before the draining transaction landed.

For protocols, exchanges, trading firms, and institutions deploying capital onchain, that early visibility is what turns a developing attack into something a security team can act on while there is still time. The protocols and desks that come through incidents intact are the ones watching the chain in real time, positioned to move in the narrow window between an attacker's setup and execution, rather than confirming the loss once the funds have already moved.

The Growing Target on Deprecated and Unmaintained Protocols

Relic protocols are increasingly in attackers' crosshairs. As newer infrastructure draws the attention of security teams and researchers, the contracts that have been deprecated or left without active support are where value still sits with the fewest people watching it. Aztec Connect is a clear case, a system wound down years ago, still holding user funds, drained through a flaw in code no one was maintaining.

Outdated code and lapsed support are what make these systems vulnerable. A flaw that would be patched quickly in a live protocol can sit untouched for years in one that is no longer maintained, and the same dependencies that made the protocol useful keep value parked in it long after the team has moved on. AI-powered threats are accelerating this trend, lowering the cost of combing through old, unverified code to find and weaponize exactly these latent flaws. The result is a growing surface of forgotten contracts that remain a live liability, and the only practical way to manage that risk is continuous, external monitoring of the code that is no longer being looked after.

Conclusion

The Aztec Connect exploit drained approximately $2.19M through a settlement-boundary flaw, and because the contracts had been renounced years earlier, no party could pause, patch, or freeze them once the attack began. Detection could not change the outcome in this particular case. What it demonstrates is the capability that does change outcomes everywhere else. Blockaid flagged the attacker's preparation roughly six minutes before the draining transaction executed, catching the attack while it was still forming rather than after the funds had moved.

That six-minute window is the difference-maker in the far more common case where someone can act on it. A protocol watching the chain in real time can use that window to respond before an exploit lands, and an institution with capital deployed across onchain protocols can be alerted the moment a developing attack threatens its exposure. Automated systems like Blockaid's Onchain Monitoring surface that signal in real time, turning the gap between an attacker's setup and execution into the time a security team needs to make a decision in seconds and prevent the loss.

About Blockaid

Blockaid is the onchain security platform trusted by the largest companies operating in Web3. Built by veterans of elite intelligence and cybersecurity units, Blockaid provides end-to-end protection for financial institutions, protocols, and end users, combining direct wallet and dApp integrations with real-time monitoring, detection, and response across smart contracts, infrastructure, and externally owned accounts. Since 2025, Blockaid scanned over 6.3 billion transactions and blocked 585 million attacks. Blockaid is the security infrastructure behind Coinbase, MetaMask, Uniswap, Safe, and dozens of the most widely used platforms in the industry.

Learn more at blockaid.io, and follow us on Twitter and LinkedIn.