Fifty million USDT exchanged for $35,000 worth of AAVE: How did the disaster happen? Who should we blame?

This article is from: @Ehsan1579

Compiled by Odaily Planet Daily (@OdailyChina); Translator: Ethan (@ethanzhang_web3)

At first glance at the event title, one might easily mistake this for a vulnerability exploit attack.

The core of the incident is: Someone exchanged $50.4 million worth of USDT for only $35,900 worth of AAVE.

When I first heard about this, I was truly shocked. Therefore, I thoroughly analyzed the entire event: transaction tracking, solver paths, contract calls, historical reserves, settlement data, adapter flows, Aave interface code, CoW flash loan SDK, and the routing code that judges whether the quote is “reasonable.”

This is not a hacking attack. The core Aave protocol did not malfunction. The CoW settlement was correct. Uniswap was fine. SushiSwap was fine. The transaction was valid, the signature was valid, and all contracts executed strictly according to code. Yet, almost all the economic value was destroyed simply because the route it was allowed to take was absurdly malicious.

The public chain is not at fault; the problem lies in the routing.

In my view, dismissing this as merely “user error” is not an objective or rigorous stance. Sure, the user signed the order, but the entire software system allowed an operation involving nearly $50 million in collateral swaps—completing quote, signing, routing, and execution—all directed toward a low-liquidity pool holding only about 331 AAVE. This should have been impossible, or at least should have been forcibly blocked before settlement.

Transaction core info trace

The hash of this abnormal transaction is: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmed on Ethereum mainnet at block height 24,643,151 on March 12, 2026. The transaction index is 1, gas used: 3,780,570 units, execution successful. The wallet address owning the order starts with 0x98b9; the solver (transaction sender) address is 0x3980, marked as tsolver in CoW competition data.

First, understand that this is not a simple USDT to AAVE swap at the wallet level. The token sold is aEthUSDT, representing interest-bearing USDT deposits on Aave. The token bought is aEthAAVE, interest-bearing AAVE deposits. Essentially, this is an Aave collateral swap executed via CoW’s settlement system and its flash loan adapter flow.

Before the transaction, the wallet held about 50,432,693.075254 aEthUSDT and 0 aEthAAVE. Afterward, it only has 4.980399 aEthUSDT and received 327.241335505966487788 aEthAAVE. In effect, it sold nearly all its position.

Metadata clarifies that the route was “poisoned” before execution. The order originated from the aave-v3-interface-collateral-swap process. CoW’s API shows it as a signed sell order, while application metadata marks it as a market swap with 121 basis points of smart slippage. The signed sell amount was 50,432,688.41618 aEthUSDT. The minimum buy amount signed was 324.949260918413591035 aEthAAVE. The actual settlement paid was 327.241335505966487788 aEthAAVE.

This is a crucial detail. The order was never meant to receive thousands of AAVE and then be destroyed mid-process. From the start, it was built around a result of just a few hundred AAVE.

Complete route collapse chain

Following the transaction trace, the entire process is brutally straightforward.

The top-level fund flow relies on CoW’s 0x9008 GPv2Settlement contract. First, the 0x60bf HooksTrampoline contract authorizes aEthUSDT, allowing CoW’s relayer to extract user assets without separate approval. Then, the 0xc92e GPv2VaultRelayer contract pulls 50,432,688.41618 aEthUSDT from the user’s wallet into the settlement process—this step is normal.

Next, the settlement contract grants aEthUSDT permissions to an unopen-sourced auxiliary contract at 0xd524…, invoked via function selector 0x494b3137. This auxiliary contract then delegates execution rights to an unopen-sourced executor contract at 0x699c… This fully exposes the malicious route.

The first valid call targets the Aave pool at 0x87870…, calling withdraw (selector 0x69328dec) to burn aEthUSDT and redeem underlying USDT. Then, the route jumps to the Uniswap V3 pool at 0x4e68…, swapping all 50,432,688.41618 USDT for 17,957.810805702142342238 WETH.

This stage of the transaction is entirely normal: the exchange rate is about 2808.4 USDT per WETH, consistent with market conditions at the time, with no liquidity issues or calculation errors. The first hop chain is free of anomalies.

The problem appears at the second hop—once you see the liquidity reserves, the story becomes unavoidable.

After receiving 17,957.810805702142342238 WETH, the executor transfers all funds into a SushiSwap V2 pool at 0xd75e…, AAVE/WETH pair.

I checked the pool’s reserve data just before the abnormal transaction (block 24643150): it held only:

• 331.631982538108027323 AAVE
• 17.653276196397688066 WETH

This is not a data entry error; it’s a hard fact.

This route injected nearly 17,958 WETH into a tiny pool with only about 17.65 WETH reserves and a total AAVE reserve of just 331.63. The input WETH was roughly 1017 times the pool’s WETH reserve.

This is not a “slippage” or “slightly thin liquidity” issue but an extremely absurd market order execution path—forcing a tiny constant product AMM pool to handle a transaction thousands of times larger than its capacity.

The AMM pool executed the operation according to its algorithm, nearly draining all its AAVE reserves.

The core swap event on SushiSwap triggered: executing the transfer of 17,957.810805702142342238 WETH, only to receive back 331.305315608938235428 AAVE. After the trade, the pool’s remaining liquidity is approximately:

• 0.326666929169791895 AAVE
• 17,975.464081898540030304 WETH

In plain terms, about 99.9% of the pool’s AAVE was drained in one jump.

Based on pre-trade reserves, the implied AAVE price was about $149.50. The actual execution price was roughly 154,114.66 USDT per AAVE—over 1000 times the pre-trade spot price.

Subsequently, these AAVE were supplied back into the Aave pool via the supply function (selector 0x617ba037), resulting in newly minted aEthAAVE tokens sent to the settlement contract. The settlement then transferred 327.241335505966487788 aEthAAVE to the user. About 4.06398010297174764 aEthAAVE remained in the settlement contract as surplus relative to what the user paid.

Thus, the settlement did not distort a good execution into a bad one; it simply finalized the route that had already produced this result.

This is the key point: the disastrous outcome was “pre-set” before route execution.

In the embedded auxiliary contract call data within the route, the buy target amount was about 331.272185078031026739 AAVE, the user-signed minimum buy was 324.949260918413591035 AAVE, and the actual settlement amount was 327.241335505966487788 AAVE—all locked in the hundreds of AAVE range before settlement.

This route was inherently bad from the start.

Where is the vulnerability?

Answer: Every layer of the system’s validation checks the wrong dimension.

All levels only verify whether the transaction is executable, signatures are valid, amounts are non-zero—but almost no core layer checks whether the route makes economic sense. This is the fundamental failure of the mechanism.

Flaws in Aave interface adapter quote path code

The first obvious code anomaly appears in the Aave interface’s CoW adapter quote process: the function that normally attaches adapter-specific application data when requesting a quote was forcibly disabled.

Source: rates.helpers.ts:93 and adapters.helpers.ts:194

This means that when Aave’s interface requests a quote from CoW, it does not include the actual flash loan and hook metadata that would be attached when placing an order. In other words, what is being quoted is not exactly what will be executed. The code comment even states that this helper function is meant to make adapter quotes more precise, yet it was forcibly disabled.

The rationality check in CoW’s quote competition logic is too weak (core vulnerability)

The second, and most serious, issue lies in CoW’s quote competition logic: its public code only checks if the quote’s gas cost is positive and the output amount is non-zero—then it considers the quote “reasonable.”

Source: quote.rs:31

For a routing system handling eight-figure orders, this is an astonishingly weak “reasonableness” standard.

The system does not incorporate oracle-based price sanity checks, does not have mechanisms to block “quotes deviating more than 500x from spot prices,” does not assess the risk of “completely draining liquidity pools,” nor does it warn about “final hop liquidity being severely mismatched with order size.” It only requires the solver to return an executable, non-zero route, which it then accepts—this is the core vulnerability of this incident.

Flaws in Uniswap V2-style liquidity modeling

The third issue concerns Uniswap V2’s liquidity pool model: the code only uses the standard constant product formula, rejecting zero reserves, underflows, overflows, etc., but does not perform economic feasibility checks.

Source: pool_fetching.rs:118 and 153

This code does not verify whether the pool’s size is sufficient to handle the corresponding route transaction. It only checks if the swap is mathematically valid. Therefore, even a tiny pool with only 331 AAVE reserves can be deemed capable of handling a request to buy 17,957 WETH, simply because the constant product formula yields a non-zero result—completely ignoring the fact that executing such a trade would destroy the pool’s assets.

Secondary failure of the flash loan SDK and order validation

Subsequently, the flash loan SDK directly embeds this invalid quote into the order and hook payloads without any risk interception.

Then:

Source: index.js:484 and 591

This is why I keep saying this route was “bad from the start.” The adapter layer did not “detect” the bad amount during execution. It serialized the already-quoted bad amount into hook data and fixed addresses. Once a bad quote exists, all subsequent mechanisms faithfully pass it along.

Even CoW’s order validation logic did not truly protect users, because it only checks if the order exceeds market prices at quote time, not whether the quote itself is absurd relative to actual liquidity.

Source: order_validation.rs:694

This is a consistency check: if the quote is already nonsense, the order can still pass.

UI front-end warning system is ineffective

Aave’s interface does have high-price impact warnings, but they are not hard circuit breakers. When the loss exceeds 20%, it becomes a confirmation checkbox.

Once the user checks this box, the obstacle is removed:

Source: helpers.ts:24 and HighPriceImpactWarning.tsx:35

Thus, even if the transaction nearly empties all assets, the system only treats it as a user-confirmed operation, not a high-risk transaction that must be rejected. The warning mechanism fails to effectively prevent risk.

Given all these systemic failures, I strongly disagree with the dismissive conclusion that “it was just user stupidity.” The user did sign, but the entire software system had countless opportunities to intercept this disaster—yet each layer only performed basic checks, passing it as “non-zero, executable, signed,” leading to the final catastrophe.

Routing was not tampered with

This part is crucial, ruling out many false hypotheses: the aave-v3-interface-collateral-swap process on the official Aave UI, at line 139 in useSwapOrderAmounts.ts, calculates the slippage-adjusted buy amount based on quote, network fees, partner fees, flash loan costs; line 331 converts this to buyAmountBigInt; then, at line 191 in CollateralSwapActionsViaCoWAdapters.tsx, it completes precise signing of this amount.

Subsequently, the adapter contract at AaveV3BaseAdapter.sol line 141 verifies that the signed order fields match the stored values exactly; the CoW settlement contract at GPv2Settlement.sol line 337 enforces the signature’s limit rules. Therefore, the on-chain execution results did not exceed the signed order’s scope, and the assets actually received by the user even exceeded the signed minimum.

This proves: the disaster occurred before settlement, and the route’s fatal flaw was predetermined.

Where did the vanished value go?

The next transaction in the same block (hash starting 0x45388b0f) performed a back-running arbitrage on the compromised SushiSwap AAVE/WETH pool. After the abnormal transaction flooded the pool with WETH and drained most of the AAVE, the arbitrageur immediately sold AAVE back into the pool, harvesting the excess value created by the imbalance.

This back-run arbitrage extracted about 17,929.770158685933 WETH, then paid roughly 13,087.73 ETH to the block builder, and about 4,824.31 ETH to the arbitrage executor.

All the economic value lost by the user was almost instantly converted into MEV arbitrage gains and block builder profits within the same block.

Further block-level timestamp analysis confirms: before the abnormal transaction, no malicious manipulation of the SushiSwap pool was detected. The first interaction with this AAVE/WETH pair was the abnormal transaction itself (index 1). The immediate next transaction (index 2) was the first back-run exploiting the price distortion caused by the abnormal trade; transaction 3 also touched this pair during market recovery. The timeline clearly shows that the abnormal trade caused extreme price distortion, which subsequent trades directly exploited for profit.

Who is at fault?

If you ask whether the core Aave V3 protocol collapsed, the answer is no. The Aave pools executed withdrawal and deposit operations normally, following instructions.

If you ask whether CoW’s GPv2Settlement contract failed, the answer is no. It enforced a valid signed order and paid an amount above the signed minimum.

If you ask whether Uniswap V3 or SushiSwap pools failed, the answer is no. Both pools executed trades according to their algorithms.

The real systemic failure lies in the higher-level routing and risk control layers:

The main responsibility lies with CoW’s routing, quote, and solver modules: the entire system’s criteria for “reasonable routing” are too weak, allowing multi-million-dollar orders to flow into tiny, low-liquidity pools, simply because as long as the route is executable and non-zero, it is accepted—completely ignoring extreme economic irrationality.

The secondary responsibility lies with the Aave frontend interface: when requesting adapter quotes, it did not attach hook-related application data, passing incorrect results into the signing process, and relied only on warnings without hard rejection. For such large, extreme trades, these risk controls are utterly insufficient.

This is an extreme failure of route quality and risk management, turning a legitimate collateral swap into a catastrophic loss.