50 Million USDT Swapped for $35,000 Worth of AAVE: How Did the Disaster Happen? And Who’s to Blame?

Compiled by | Odaily (@OdailyChina); Translator | Ethan (@ethanzhang_web3)

At first glance, the event title might easily be mistaken for an exploit.

The core of the incident is: Someone exchanged $50.4 million worth of USDT for only $35.9k worth of AAVE.

When I first heard about this, I was genuinely shocked. Therefore, I thoroughly dissected the entire event: transaction tracing, solver path, contract calls, historical reserves, settlement data, adapter flow, Aave interface code, CoW flash loan SDK, and the routing code that determines whether a quote is “reasonable.”

This was not a hack. The Aave core protocol did not malfunction. The CoW settlement did not malfunction. Uniswap did not malfunction. SushiSwap did not malfunction. The transaction was valid, the signature was valid, all contracts executed strictly according to their code. Yet, almost all economic value was destroyed simply because it was allowed to take an absurdly flawed route.

The public chain did not fail; the routing did.

In my view, dismissing this as a simple “user error” is neither objective nor rigorous. While the user did sign the order, the entire software system allowed an operation involving nearly $50 million in collateral rotation to proceed through quoting, signing, routing, and final execution, with the entire flow pointing to a low-liquidity pool holding only about 331 AAVE. This should have been completely impossible, or at the very least, the system should have firmly rejected it before settlement was initiated.

Tracing the Core Transaction Information

The anomalous transaction hash is: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmed on the Ethereum mainnet at block height 24643151 on March 12, 2026, with transaction index 1, consuming 3,780,570 gas units, and executed successfully. The order belongs to wallet address starting with 0x98b9, and the actual executing solver (transaction sender) address starts with 0x3980, marked as ‘tsolver’ in CoW competition data.

First, understand that this was not a simple wallet-level USDT-to-AAVE swap. The sold token was aEthUSDT, the interest-bearing USDT deposit token on the Aave platform. The bought token was aEthAAVE, the interest-bearing AAVE deposit token on the Aave platform. Therefore, this was actually an Aave collateral rotation conducted through CoW Protocol’s settlement system and its flash loan adapter flow.

Before the transaction, the wallet held approximately 50,432,693.075254 aEthUSDT and 0 aEthAAVE. After the transaction, it was left with only 4.980399 aEthUSDT and received 327.241335505966487788 aEthAAVE. Essentially, the wallet sold almost its entire position.

The metadata more clearly indicates that the route was “toxic” even before execution. The order originated from the aave-v3-interface-collateral-swap flow. CoW’s API shows it as a signed sell order, and the app metadata marks it as a market-style collateral swap using 121 basis points of intelligent slippage. The signed sell amount was 50,432,688.41618 aEthUSDT. The signed minimum buy amount was 324.949260918413591035 aEthAAVE. The actual settlement paid 327.241335505966487788 aEthAAVE.

This is an extremely important detail. This order was never expecting to receive thousands of AAVE that somehow got destroyed mid-way. From its construction, it was built around an outcome of just over three hundred AAVE.

The Complete Chain of the Routing Collapse

Once you follow the transaction trace, the entire process is brutally straightforward.

The top-level fund flow relies on CoW Protocol’s GPv2Settlement contract starting with 0x9008. First, the HooksTrampoline contract (0x60bf…) performs the aEthUSDT approval, allowing the CoW vault relayer to pull user assets without a separate approval transaction. Then, the GPv2VaultRelayer contract (0xc92e…) withdraws 50,432,688.41618 aEthUSDT from the user’s wallet into the settlement process. Up to this point, all operations follow normal logic.

The settlement contract then grants aEthUSDT operation permission to an unverified auxiliary contract (0xd524…) and initiates a call via function selector 0x494b3137. This auxiliary contract transfers execution authority to an unverified executor contract (0x699c…). Here, the full picture of the anomalous transaction route is completely exposed.

The first effective call points to the Aave pool contract (0x87870…), using the withdraw function (selector 0x69328dec) to burn aEthUSDT and redeem the underlying native USDT. The route then jumps to the deep USDT/WETH Uniswap V3 pool (0x4e68…), swapping all 50,432,688.41618 USDT for 17,957.810805702142342238 WETH.

This stage of the trade was completely normal: the exchange rate was approximately 2,808.4 USDT per 1 WETH, matching market conditions at the time, with no liquidity shortage or calculation deviation. The first hop of the transaction path showed no abnormalities.

The problem lies in the second hop. Once you see the liquidity reserves, the rest of the story becomes inevitable.

After obtaining 17,957.810805702142342238 WETH, the executor transfers all funds into the SushiSwap V2 AAVE/WETH pool at address 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

I checked the historical liquidity reserve data for this pool at the moment before the anomalous transaction (block height 24643150). The pool held only:

331.631982538108027323 AAVE, 17.653276196397688066 WETH

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

This transaction route injected nearly 17,958 WETH into a micro-pool that only held 17.65 WETH in reserve, corresponding to a total AAVE inventory of just 331.63. The input WETH volume was approximately 1,017 times the pool’s WETH reserve.

This is not a routine issue of “high slippage” or “slightly thin liquidity.” This is an extremely absurd market order execution path, equivalent to forcing a tiny constant product AMM pool to handle a massive trade thousands of times its own size.

The AMM pool executed the operation according to its algorithm, nearly exhausting the pool’s entire AAVE reserve.

The SushiSwap pair triggered the core Swap event: the executor transferred in 17,957.810805702142342238 WETH and received only 331.305315608938235428 AAVE in return. After the trade, the pool’s remaining liquidity was approximately:

0.326666929169791895 AAVE, 17,975.464081898540030304 WETH

In plain terms, about 99.9% of the pool’s AAVE inventory was drained in a single hop.

Based on pre-trade reserves, the pool’s implied AAVE price was approximately $149.50. The user’s actual execution price was about 154,114.66 USDT per 1 AAVE. This is over 1,000 times worse than the pre-trade spot price.

Next, these AAVE were supplied back to the Aave pool using selector 0x617ba037, i.e., supply(address,uint256,address,uint16). The result was newly minted aEthAAVE sent back to the settlement contract. The settlement contract finally transferred 327.241335505966487788 aEthAAVE to the user. Approximately 4.06398010297174764 aEthAAVE remained in the settlement contract as surplus relative to what the user paid.

Therefore, the settlement did not suddenly twist a good execution result into a bad one. It merely finalized the result that the route had already produced.

This is the key point, worth stating explicitly: The catastrophic outcome was “baked in” before the route was even executed.

Within the embedded auxiliary contract call data of the route, the buy-side target amount was approximately 331.272185078031026739. The user’s signed minimum buy amount was 324.949260918413591035. The actual settlement amount was 327.241335505966487788. All core values were locked at the scale of just over three hundred AAVE before settlement.

This route was born broken.

Where is the Vulnerability?

The answer: Every layer of the system’s verification mechanism was checking the wrong dimension.

All layers only verified whether the transaction was executable, the signature was valid, and the amount was non-zero. However, almost no core layer verified whether the transaction route was economically reasonable. This is the core root cause of the mechanism’s failure.

Code Defect in the Aave Interface Adapter Quote Path

The first obvious code anomaly appears in the Aave interface’s CoW adapter quote flow: The function originally intended to attach adapter-specific app data when requesting a quote was forcibly disabled.

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

This means the Aave interface, when requesting a quote from CoW, did not attach the flash loan and hook metadata that would actually be attached when posting the order. In other words, what was being quoted was not exactly what would be executed. The code comment even says the purpose of this helper function is to make adapter quotes more accurate, yet the function was hard-disabled.

CoW Quote Competition Logic’s “Reasonableness” Judgment is Excessively Weak (Core Vulnerability)

The second and most severe problem lies in CoW Protocol’s quote competition logic: In its public service code, as long as a quote has positive gas fees and a non-zero output amount, it is judged as a “reasonable quote.”

Source: quote.rs:31

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

The system lacked integration with oracles for price sanity checks, no interception mechanism for “quotes deviating over 500x from spot price,” no risk assessment for “routes that would completely drain a liquidity pool,” no warning for “severe mismatch between last-hop liquidity and order size.” As long as a solver returned an executable, non-zero routing solution, it was accepted by the system. This is the core vulnerability of this incident.

Defect in Uniswap V2-style Liquidity Modeling Logic

The third problem lies in the modeling approach for Uniswap V2-style liquidity pools: The code only employs the standard constant product formula, rejecting only mathematically impossible scenarios like zero reserves, underflow, or overflow, without performing economic feasibility checks.

Source: pool_fetching.rs:118 and pool_fetching.rs:153

This code does not judge whether the pool’s size is sufficient to handle the corresponding routed trade; it only judges whether the swap operation is mathematically valid. Therefore, even a micro-pool holding only 331 AAVE would be judged as a valid venue for a buy request of 17,957 WETH, simply because the constant product formula could calculate a non-zero result, completely ignoring that this result would cause devastating asset loss.

Secondary Failure of Flash Loan SDK and Order Validation Mechanism

Subsequently, the flash loan SDK directly solidified this failed quote into the order and hook execution payload, without any secondary risk interception.

Then:

Source: index.js:484 and index.js:591

This is why I keep saying this route was “born broken.” The adapter layer did not “discover” a new bad amount at execution time. It serialized the already-quoted bad amount into the hook data and the determined instance address. Once a bad quote existed, the rest of the mechanisms faithfully passed it along.

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

Source: order_validation.rs:694

This is a consistency check. If the quote itself is already nonsense, the order can still pass.

UI Front-end Warning Mechanism is Virtually Ineffective

The Aave interface does have a high price impact warning, but it is not a hard circuit breaker. When the value loss exceeds 20%, it becomes a confirmation checkbox.

Once the user checks the box, the obstacle is cleared:

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

Therefore, even though this transaction would nearly wipe out all asset value, the system only judged it as an operation requiring user confirmation, not a high-risk transaction that the system must firmly reject. The warning mechanism completely lost its risk interception function.

Based on all the above mechanism failures, I absolutely do not agree with the perfunctory conclusion that “this was just user stupidity.” The user did sign, but the entire software system had countless opportunities to intercept this disaster. Yet, at every layer, it only performed basic checks, judged it as “non-zero, executable, signed,” and let it pass, ultimately leading to the disastrous outcome.

The Route Was Not Tampered With

This point is crucial, directly ruling out many erroneous guesses: The Aave official interface flow corresponding to aave-v3-interface-collateral-swap, in the file `useSwapOrderAmounts.ts` at line 139, calculates the slippage-adjusted buy amount by combining the quote, network fees, partner fees, and flash loan fees. Line 331 converts it to a `buyAmountBigInt` value. Subsequently, in the file `CollateralSwapActionsViaCoWAdapters.tsx` at line 191, this amount is precisely signed.

Later, the adapter contract, in `AaveV3BaseAdapter.sol` at line 141, verifies that the signed order fields match the stored values exactly. The CoW settlement contract, in `GPv2Settlement.sol` at line 337, enforces the limits agreed upon in the signature. Therefore, the on-chain execution result did not exceed the bounds allowed by the signed order; the user actually received assets even higher than the signed minimum limit.

This is sufficient proof: The disaster occurred before the settlement phase, not during it. The fatal flaw in the route had already predetermined the outcome.

Where Did the Lost Value Go?

The very next transaction in the same block (hash starting with 0x45388b0f…) performed a backrun arbitrage on the devastated SushiSwap AAVE/WETH pool. After the anomalous transaction flooded the pool with massive WETH and drained the vast majority of AAVE, the arbitrageur immediately sold AAVE back into the pool, harvesting the excess value created by the liquidity imbalance.

This backrun arbitrage extracted approximately 17,929

This article is sourced from the internet: 50 Million USDT Swapped for $35,000 Worth of AAVE: How Did the Disaster Happen? And Who’s to Blame?

Related: Did Jane Street “Manipulate” BTC? Decoding the AP System, Understanding the Power Struggle Behind ETF Creation and Redemption Pricing

“They were fcking us the whole time.” This expletive, circulating on Reddit and CT (Crypto Twitter) following the lawsuit, along with an epic short squeeze involving over $240 billion in liquidations, has directed the market’s fury towards a single target: Jane Street Capital. At 10 AM, the liquidity freeze point for the Asian market over the past few months, the tip of the iceberg was finally revealed with the U.S. Department of Justice’s complaint. It all traces back to the Wall Street top-tier market maker Jane Street Capital, founded in 2000, which is accused of executing a months-long “shell game” between spot and derivative order books by exploiting the creation and redemption mechanism of spot ETFs through targeted ETF arbitrage in the market. It wasn’t until the lawsuit brought this…