50 million USDT exchanged for 35,000 USD AAVE: How did the disaster happen? Who should we blame?

This article is from: @Ehsan1579

Compiled by: Ethan, Odaily Planet Daily

Just looking at the event title, one might mistakenly think this is a case of a vulnerability exploitation attack.

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

I was truly shocked when I first heard about this. Therefore, I thoroughly reviewed the entire event: transaction tracking, solver paths, contract calls, historical reserves, settlement data, adapter processes, Aave interface code, CoW flash loan SDK, and the routing code that determines whether the quote is "reasonable."

This is not a hacker attack. The core Aave protocol did not make a mistake. CoW settlement did not make a mistake. Uniswap did not make a mistake. SushiSwap did not make a mistake. The transaction was valid, the signature was valid, and all contracts executed strictly according to the code. However, almost all economic value was destroyed simply because the routing it was allowed to take was absurdly unreasonable.

The public chain did not have a problem; the problem was with the routing.

In my view, downplaying this incident as merely a "user operational error" is not an objective or rigorous attitude. Indeed, the user completed the order signature, but the entire software system allowed an operation involving nearly $50 million in collateral to complete the quote, signature, routing planning, and final execution, all pointing to a low liquidity pool holding only about 331 AAVE. This should have been completely impossible, and at least should have been firmly intercepted and rejected by the system before the settlement stage was initiated.

Core Information Trace of the Transaction

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

First, it is important to understand that this is not a simple wallet-level USDT to AAVE exchange. The token sold is aEthUSDT, which is the interest-bearing USDT deposit certificate on the Aave platform. The token bought is aEthAAVE, which is the interest-bearing AAVE deposit certificate on the Aave platform. Therefore, this is actually a collateral swap of Aave conducted through the CoW protocol's settlement system and its flash loan adapter process.

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. In fact, the wallet sold almost its entire position.

Metadata more clearly indicates that the routing was already "toxic" before execution. The order came from the aave-v3-interface-collateral-swap process. CoW's API displayed it as a signed sell order, while the application metadata marked it as a market-style collateral swap using 121 basis points of smart 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. The order did not expect to obtain thousands of AAVE, only to be somehow destroyed midway. From the very beginning, it was built around a result of over three hundred AAVE.

Complete Link of Routing Collapse

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

The top-level capital flow relies on the CoW protocol's GPv2Settlement settlement contract starting with 0x9008. First, the HooksTrampoline contract starting with 0x60bf completes the aEthUSDT authorization operation, allowing the CoW treasury relayer to extract user assets without separate transaction authorization; then, the GPv2VaultRelayer contract starting with 0xc92e extracts 50,432,688.41618 aEthUSDT from the user's wallet into the settlement process. Up to this point, all operations conform to normal logic.

The settlement contract then grants aEthUSDT operation authority to an unverified auxiliary contract starting with 0xd524 and initiates a call via function selector 0x494b3137; this auxiliary contract then transfers execution authority to an unverified executor contract starting with 0x699c, at which point the full picture of the abnormal transaction routing is completely exposed.

The first effective call points to the Aave liquidity pool contract starting with 0x87870, which destroys aEthUSDT through the withdraw function (selector 0x69328dec) to redeem the underlying native USDT; then the routing jumps to the Uniswap V3 deep USDT/WETH trading pool starting with 0x4e68, exchanging all 50,432,688.41618 USDT for 17,957.810805702142342238 WETH.

The transaction at this stage is completely normal: the exchange rate is about 2808.4 USDT for 1 WETH, consistent with the market at the time, with no liquidity shortage issues, and no calculation deviations; the first hop transaction link has no abnormalities.

The problem arises in the second hop; once you see the liquidity reserves, the rest of the story is inevitable.

After the executor obtains 17,957.810805702142342238 WETH, it transfers all funds to the SushiSwap V2 AAVE/WETH trading pool at address 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

I checked the historical liquidity reserve data of this trading pool just before the abnormal transaction occurred (block height 24643150), and the pool held only:

331.631982538108027323 AAVE, 17.653276196397688066 WETH

This is not a data entry error, but an ironclad fact.

This transaction routing injected nearly 17,958 WETH entirely into a micro trading pool that only reserves 17.65 WETH, corresponding to a total AAVE inventory of only 331.63 AAVE, with the input WETH volume being about 1017 times the pool's WETH reserves.

This is not a "high slippage" or "slightly thin liquidity" common issue, but an extremely absurd market order execution path, equivalent to forcing a very small constant product AMM pool to undertake a transaction scale thousands of times beyond its own capacity.

The AMM trading pool executed the operation according to the established algorithm, nearly exhausting all AAVE reserves in the pool.

The SushiSwap trading pair triggered the core Swap exchange event: the executor transferred 17,957.810805702142342238 WETH, only receiving back 331.305315608938235428 AAVE. After the transaction, the remaining liquidity in the pool was approximately:

0.326666929169791895 AAVE, 17,975.464081898540030304 WETH

In simple terms, about 99.9% of the AAVE reserves in the pool were drained in one hop.

Based on the reserves before the transaction, the implicit AAVE price in the pool was about $149.50. The user's actual execution price was about 154,114.66 USDT for 1 AAVE. This is more than 1000 times different from the spot price before the transaction.

Subsequently, these AAVE were supplied back to the Aave liquidity pool, using selector 0x617ba037, i.e., supply(address,uint256,address,uint16). The result was that the newly minted aEthAAVE was sent back to the settlement contract. The settlement contract ultimately 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 suddenly distort a good execution result into a bad one. It merely finalized the result that the routing had already produced.

This is a key point worth stating clearly: the disastrous result was already "preset" in the routing before execution.

In the auxiliary contract call data embedded in the routing, the target buy amount on the buying side was about 331.272185078031026739, the minimum buy amount agreed upon by the user was 324.949260918413591035, and the actual settlement amount was 327.241335505966487788, with all core values locked in at the level of over three hundred AAVE before settlement.

This routing was born bad.

Where is the flaw?

The answer is: every layer of the system's verification mechanism is checking the wrong dimension.

All levels only check whether the transaction is executable, whether the signature is valid, whether the amount is non-zero, but there is almost no core level checking whether the transaction routing is economically reasonable, which is the core root of the mechanism's failure.

Code Defect in Aave Interface Adapter Quote Path

The first obvious point of code anomaly appears in the CoW adapter quote process of the Aave interface: the function originally used to attach adapter-specific application data when requesting a quote was directly forced to be disabled.

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

This means that when the Aave interface requests a quote from CoW, it does not attach the flash loan and hook metadata that would actually be included when placing an order. In other words, what is being quoted is not entirely what is to be executed. The code comments even state that the purpose of this helper function is to make the adapter's quotes more accurate, yet this function was forcibly disabled.

Weak Reasonableness Determination in CoW Quote Competition Logic (Core Flaw)

The second and most serious problem lies in the CoW protocol's quote competition logic: in its public service code, as long as the quote gas fee is positive and the output amount is non-zero, it will be deemed a "reasonable quote."

Source: quote.rs:31

For a routing system handling eight-digit orders, this is a shockingly weak definition of "reasonableness."

The system did not integrate oracles for price soundness checks, had no interception mechanism for "quotes deviating from the spot price by over 500 times," no risk assessment for "routing completely draining liquidity pools," and no warning for "last hop liquidity severely mismatched with order scale;" it only required the solver to return an executable, non-zero routing plan, which would be accepted by the system, this is the core flaw of this incident.

Defects in Uniswap V2 Style Liquidity Modeling Logic

The third problem lies in the Uniswap V2 style liquidity pool modeling approach: the code only employs the standard constant product algorithm, rejecting only mathematically impossible situations such as zero reserves, underflow, and overflow, without conducting economic feasibility checks.

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

This segment of code does not determine whether the liquidity pool's size is sufficient to accommodate the corresponding routing transaction; it only checks whether the swap operation is mathematically valid. Therefore, even a micro pool with only 331 AAVE reserves would be deemed a valid place to accommodate a buy request for 17,957 WETH, simply because the constant product algorithm can yield a non-zero result, completely ignoring the catastrophic asset loss this result would cause.

Secondary Failure of Flash Loan SDK and Order Verification Mechanism

Subsequently, the flash loan SDK directly solidified this invalid 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 have always said this routing is "born bad." The adapter layer did not "discover" a new bad amount during execution. It serialized the already quoted bad amount into the hook data and determined instance address. Once a bad quote exists, the remaining mechanisms will faithfully pass it along.

Even CoW's order verification logic here did not truly protect the user, as it only checks whether the order exceeds the market price at the time of quoting, without checking 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 nonsensical, the order can still pass.

UI Frontend Warning Mechanism is Ineffective

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

Once the user checks the checkbox, the barrier is removed:

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

Therefore, even if this transaction would nearly empty all asset value, the system only deemed it an operation requiring user confirmation, rather than a high-risk transaction that must be firmly rejected by the system, and the warning mechanism completely lost its risk interception function.

Based on all the above mechanism failures, I absolutely do not agree with the dismissive conclusion that "this is just user stupidity." The user did complete the signature, but the entire software system had countless opportunities to intercept this disaster, yet each layer only performed basic checks, determining "non-zero, executable, signed," and directly released it, ultimately resulting in disastrous consequences.

Routing Was Not Tampered With

This section is crucial, directly ruling out a large number of erroneous speculations: the Aave official interface process corresponding to aave-v3-interface-collateral-swap will calculate the slippage-adjusted buy amount at line 139 of the useSwapOrderAmounts.ts file, combining the quote, network fees, partner fees, and flash loan fees; line 331 converts it to the buyAmountBigInt value; then at line 191 of the CollateralSwapActionsViaCoWAdapters.tsx file, this amount is precisely signed.

Subsequent adapter contracts will verify that the signed order fields completely match the stored values at line 141 of the AaveV3BaseAdapter.sol file; the CoW settlement contract will enforce the signed agreed limit rules at line 337 of the GPv2Settlement.sol file. Therefore, the on-chain execution result did not exceed the limits allowed by the signed order, and the assets the user actually received were even above the minimum limit agreed upon in the signature.

This is sufficient to prove: the disaster occurred before the settlement stage, not during the settlement process; the fatal flaw in the routing had already predetermined the outcome.

Where Did the Disappeared Value Go?

The next transaction in the same block (hash starting with 0x45388b0f) completed a back-run arbitrage against the damaged SushiSwap AAVE/WETH pool. After the abnormal transaction filled the pool with a massive amount of WETH and drained most of the AAVE, the arbitrageur immediately sold the AAVE back into the pool, harvesting the excess value brought by the liquidity imbalance.

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

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

Additionally, checking the block-level time sequence confirms: no one maliciously manipulated the SushiSwap trading pool to set a trap for users; the AAVE/WETH trading pair was first touched by this abnormal transaction (transaction index 1); the immediately following transaction (transaction index 2) completed the first back-run against the price distortion caused by this transaction; transaction index 3 also touched this trading pair during the market correction process. The timeline clearly verifies: this abnormal transaction created an extreme price distortion, and subsequent transactions directly harvested this distorted profit.

So, whose fault is it?

If you ask whether the Aave V3 core protocol collapsed, the answer is no. The Aave liquidity pool executed operations completely according to instructions, successfully completing the USDT redemption and AAVE deposit process.

If you ask whether the CoW's GPv2Settlement contract collapsed, the answer is no. The settlement enforced a valid signed order and paid an amount above the minimum limit agreed upon in the signature.

If you ask whether the trading pair contracts of Uniswap V3 or SushiSwap collapsed, the answer is also no. Both types of trading pools completed transaction pricing according to their own algorithm rules.

The real systemic failure occurred at the higher-level routing and risk control layers:

The primary responsible party is the routing, quoting, and solver modules of the CoW protocol: the entire system's criteria for determining "reasonable routing" are too weak, allowing multi-million dollar orders to ultimately flow to micro low liquidity pools, as long as the routing is executable and non-zero, it is accepted, completely ignoring the extreme unreasonableness on the economic level.

The secondary responsible party is the Aave frontend interface: it did not attach the application data associated with the hook when requesting adapter quotes, directly passing erroneous results into the signing process, and relied solely on warning prompts without a hard rejection mechanism. For such extreme large transactions, these risk control measures are completely insufficient to prevent risks.

This is an extreme failure of transaction routing quality and risk control barriers, directly transforming a legitimate and compliant collateral swap operation into a catastrophic asset loss event.