Aztec Connect: $2.19M stolen from a dead contract

A contract that had been unpatchable for over two years by its own team's decision lost approximately $2.19 million in a single transaction. On June 14, 2026, an attacker drained the RollupProcessor contract of Aztec Connect —a privacy bridge on Ethereum that Aztec Labs had deprecated (retired from service)—. Aztec Connect announced its closure in March 2023 (deposits cut off on March 31) and renounced its admin keys (the management keys that allow modifying or pausing a smart contract) a year later, in March 2024, upon shutting down the sequencer. From that renunciation of keys —the moment the contract became truly unpatchable— until the exploit, about two years and three months passed. The team did what the community considers "the right thing": ensuring that no one, not even them, could touch it. The problem is that the money was still inside. This article analyzes why deprecating a protocol and leaving it immutable with live funds is not maximum security, but rather a latent bug turned into a bomb without a defuser, and what a responsible shutdown should include.

What exactly happened at Aztec Connect on June 14?

On June 14, 2026, an attacker interacted with the Aztec Connect RollupProcessor contract on Ethereum and extracted, in a single atomic transaction (all or nothing, without reversible intermediate steps), a basket of assets valued at around $2.19 million. According to the breakdown published by SlowMist (a blockchain cybersecurity firm based in China, known for its forensic analysis of DeFi hacks), the loot included ETH, DAI, wstETH, LUSD, and several Yearn vaults (yvDAI, yvWETH, yvLUSD). The funds moved from the contract to an intermediate bridge contract and from there to an external wallet controlled by the attacker.

One detail worth highlighting: at the close of the technical analyses, and according to SlowMist, 100% of the funds remained intact in the attacker's address, without the laundering process having begun. This is relevant because it means it was not a desperate theft to move quickly, but rather the calm exploitation of a target that had gone unmonitored for years.

Aztec Labs and the Aztec Foundation confirmed that the exploited contract has no relationship with the AZTEC token or the smart contracts of the current Aztec network. The damage was confined to the legacy product. However, the episode did not end there: a second blow arrived three days later.

Was there a second exploit and why does the timeline matter?

On June 17, 2026, a second incident affected another legacy contract in the Aztec ecosystem —described by various sources as an emergency withdrawal mechanism (escapeHatch) of a similarly deprecated private rollup bridge—. Reported amounts vary between $2.15 and $2.21 million depending on the source (Coinpedia cited it at around $2.16M; CryptoTimes at about $2.21M), averaging ~$2.16M across sources. Added to the $2.19 million from the first strike, outlets like CoinJournal and NullTX estimated losses at over $4 million in three days across two different legacy systems.

BlockSec (an on-chain analysis and smart contract auditing firm) described both incidents as linked to "public inputs binding issues" (how the contract ties the input data of a cryptographic proof to what is actually settled), although it clarified that the attack methods were not identical. The chronology matters because it illustrates a pattern: the same team, several contracts shut down years ago, all unpatchable, all with balances, falling one after another in a matter of days. It is not bad luck; it is the predictable result of a design decision.

Cautionary note: the exact figures for the second incident and the aggregate total were not yet consolidated among all sources at the time of writing. We treat them as attributed reports, not as definitive figures.

Why did a contract deprecated in 2023 still have millions inside?

Here lies the paradox that gives meaning to the entire case. Aztec Connect was a bridge that allowed users to move assets into a private environment on Ethereum and operate with them. When Aztec Labs decided to pivot to a new network, it announced the product's closure in March 2023, cut off deposits on March 31, and opened a window for users to withdraw their funds. Only a year later, in March 2024 —after that window closed— it shut down the sequencer and renounced the admin keys, freezing the contract permanently.

But "opening a withdrawal window" is not the same as "emptying the contract." There are always users who don't find out, who lost their keys, who gave the money up for lost, or who simply failed to act. Two years after welding the door shut, that remnant —the money of the people who never returned— remained deposited in a contract that no one was operating. In industry jargon, this is orphan TVL (total value locked): live capital inside dead code.

• The product was dead: no assigned team, no active monitoring, no new audits.
• The money was alive: ETH, stablecoins, and yield-bearing assets, perfectly extractable for whoever found the flaw.
• The contract was immutable: neither the team nor anyone else could withdraw that remnant, pause it, or patch it.

That combination —neglect + balance + immutability— is exactly what turns a deprecated protocol into a target that improves over time. The more time passes, the fewer eyes watch it, and the more it is forgotten that the money is still there.

How did the boundary gap exploit work?

Imagine an airport security checkpoint with 32 gates in a row, but only one guard who is physically present only at the last one. The airport rule states that "all passengers passing through these gates are recorded as verified." The registration system, indeed, marks all 32 as verified. But the guard, in practice, only checks whoever crosses his gate. The other 31 gates are recorded as controlled without anyone actually controlling them.

That is, in essence, what happened. In a ZK-rollup system (a technology that bundles many transactions, generates a cryptographic proof that all are valid, and settles it on Ethereum), there are two pieces that must match:

• The cryptographic proof states how many operations are committed to the new state. In the contract, that number is related to data slots —32 in total in each batch—.
• The settlement contract on Ethereum (the L1 layer, where money actually changes hands) iterates through those operations to move funds and should verify each one.

The flaw, according to SlowMist and BlockSec, was a discrepancy between both ranges: what the proof committed as a valid state (the record saying "32 verified") and what the L1 settlement loop actually verified (the guard only looking at one gate). The technical term is boundary gap: a hole at the frontier between the off-chain verification of the proof and the on-chain verification of the settlement.

In practice, the attacker managed to have 31 of the 32 slots committed to the L2 state by the proof without passing through any settlement verification in the L1 contract. They inserted withdrawal instructions through those 31 "recorded but uncontrolled" gates, and the contract released the funds believing everything was validated. And since the contract was immutable, there was no way to close the door once it was discovered.

The important thing about this type of flaw is that it is not a gross programming error, like a forgotten require or a public function that should be private. It is a boundary design flaw: two components that individually work well —proof generation and the settlement loop— but whose assumptions about "what counts as verified" do not exactly match. These gaps at the boundaries are notoriously difficult to detect in audits because each piece looks correct in isolation; the hole only appears when they are viewed together and under a purposefully constructed transaction. This is why SlowMist insists on auditing the logical consistency of the L1/L2 boundary and the secondary on-chain verification of public inputs as its own risk category, not just another code detail.

Why can renouncing admin keys be a mistake?

This is the uncomfortable thesis of the article. The dominant intuition in crypto is that renouncing admin keys is equivalent to maximum security: "no one can touch the contract, not even the team, so no one can steal or censor." For a privacy protocol, it also has a strong ideological appeal: the absence of an administrator is proof that there is no backdoor.

The problem is that immutability is a double-edged sword. Immutable also means unpatchable. Renouncing keys eliminates the risk of a malicious (or compromised) administrator stealing funds, but in exchange, it also eliminates the only tool to react when a bug appears. And bug-free code does not exist; there is only code with bugs that haven't been found yet.

While a protocol is live, that bet might make sense: there is a team watching, a community, audits, bug bounties. But a deprecated protocol loses all of that while retaining the worst: the balance and the inability to act. Renouncing keys without first emptying the funds is not handing over the keys to an empty safe; it is welding the door of a full safe shut and throwing away the blowtorch. The day someone finds a way to open it from the side, there is no one with the authority —or technical capacity— to defend it.

The mirror case demonstrates this from the other extreme. In late May 2026, the legacy lockers of DxSale (a token launch and liquidity locking platform on BNB Chain) lost about $7.3 million, but for the opposite reason: the admin keys had not been renounced; they were silently transferred months earlier and abused to drain over 1,400 pools. Aztec renounced the keys and was robbed via a bug; DxSale kept the keys and was robbed via the keys. The common factor is not the keys: it is the money left inside a system that no one was looking after anymore. The vector changes; the root cause is the same.

How does it compare to other "dead code" cases?

Aztec Connect is not the first legacy protocol to bleed years after dying. The table summarizes three recent episodes from 2026 where the common denominator is live capital in neglected infrastructure, with different vectors.

The cross-reading provides the headline: both renouncing keys (Aztec) and keeping them poorly guarded (DxSale) end in the same result when there is a balance in a system no one operates. Key governance is secondary; the primary error is not having withdrawn the funds upon closing. A deprecated and empty contract does not appear on any target list.

There is also a temporal bias that aggravates the case of immutable contracts compared to those with a compromised administrator. A contract with a live administrator receives patches, key rotations, and surveillance as long as someone operates it; its attack surface can shrink over time. An immutable and deprecated contract does the opposite: its attack surface only grows, because the code is frozen on the day of closure while analysis techniques and attacker tools continue to improve year after year. The Aztec Connect contract was, in 2026, exactly as secure as when it was frozen in March 2024 —but the world around it was much better at finding flaws—. Time works against code that cannot change.

How should a protocol be deprecated responsibly?

The sector treats "deprecate and forget" as a neutral operation: the closure is announced, a withdrawal window is opened, and it is considered finished. But as long as a balance remains, the protocol continues to be a security liability. A responsible shutdown —a well-executed sunset— should treat the remnant as the central problem, not a detail.

• Forced withdrawal of the remnant: retain the technical capacity to sweep unclaimed funds (to a custody contract, a foundation multisig —a contract requiring multiple signatures to move funds, with no single point of failure— or a subsequent claim mechanism) before welding the door shut. An empty contract is immune by definition.
• Renounce keys after, not before: immutability as the final step, once TVL is at zero or an accepted minimum, not as a symbolic gesture on the day of the announcement.
• Pause button retained during transition: maintain a pause button (a function that freezes the contract without allowing funds to be moved) with a time-lock (a public delay before any action takes effect) for the duration of the window, to be able to freeze the contract if a flaw appears without being able to move funds arbitrarily.
• Audit of the shutdown state: specifically audit the emergency withdrawal path and the L1/L2 boundaries, which is exactly where both Aztec contracts failed.
• Post-mortem monitoring: if by design one cannot act, at least monitor the dead contract and publicly warn of the residual balance, so the risk is explicit and not a buried mine.

SlowMist, in its own analysis, recommends exactly this for deprecated contracts that still custody assets: orderly migration or destruction of funds to eliminate continuous exposure. The lesson is not "don't renounce keys"; it is "don't leave money behind a door you decide you can never open again."

What are the lessons for the reader?

For those who use DeFi, the episode leaves a concrete guideline: when a protocol announces it is closing, the withdrawal window is the only time the system still has someone looking after it, and a forgotten balance in a deprecated contract is not "stored," but exposed and with no one capable of defending it. The intuition to correct is equating "immutable" with "secure": immutability protects against a malicious administrator but leaves you defenseless against an unpatched bug, and in a dead protocol —without surveillance and with money inside— the worst possible combination occurs. This is why the recommendation SlowMist draws from the case is not "don't renounce keys," but to migrate or destroy assets from legacy contracts that still custody funds before welding the door shut: "dead protocol, live money" remains one of the worst-managed attack surfaces in DeFi precisely because it disguises itself as a best practice.

Sources and links: SlowMist — technical analysis of the exploit · NewsBTC — long-tail risk of deprecated crypto contracts · Cryptopolitan · CoinJournal — second incident · Crypto Briefing · Rekt News — DxSale