This article comes from: @Ehsan1579

Translated by｜Odaily Planet Daily（@OdailyChina）；Translator｜ Ethan（@ethanzhang_web 3）

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

The core of the event is: Someone exchanged USDT worth 50.4 million dollars and ultimately received only AAVE worth 35,900 dollars.

I was truly shocked when I first heard about this incident. Therefore, I thoroughly sorted out 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 for determining whether quotes are “reasonable.”

This was not a hacker attack. Aave’s core protocol did not malfunction. CoW settlement did not malfunction. Uniswap did not malfunction. SushiSwap did not malfunction. The transaction was valid, the signatures were valid, and all contracts were executed strictly according to the code. However, nearly all economic value was destroyed simply because the routing allowed 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 operation mistake" is not an objective and rigorous attitude. Indeed, the user completed the order signature, but the entire software system inexplicably allowed an operation involving nearly 50 million dollars in collateral rotation to complete the quote, signature, routing planning, and ultimate execution, all pointing to a low liquidity pool that holds only about 331 AAVE. This should have been completely impossible, at least the system should have forcefully intercepted and rejected it before the settlement stage was initiated.

Core Transaction Information Traceability

The hash of this anomalous 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 successfully executed. The wallet address belonging to the order starts with 0x98b9, while the address of the solver that actually executed the transaction (the transaction sender) starts with 0x3980 and is marked as tsolver in the CoW competition data.

First, it should be understood that this is not a simple wallet level USDT to AAVE swap. The sold token is aEthUSDT, which is the interest-bearing USDT deposit certificate on the Aave platform. The purchased token is aEthAAVE, which is the interest-bearing AAVE deposit certificate on the Aave platform. Thus, this is actually an Aave collateral rotation conducted through CoW’s settlement system and its flash loan adapter process.

Before the transaction, this wallet held approximately 50,432,693.075254 aEthUSDT and 0 aEthAAVE. After the transaction, it only had 4.980399 aEthUSDT left and received 327.241335505966487788 aEthAAVE. In reality, the wallet sold nearly all of its position.

Metadata more clearly indicates that the routing was "toxic" even before execution. The order came from the aave-v3-interface-collateral-swap process. CoW's API displayed it as a signed sell order, while application metadata marked it as using 121 basis points of smart slippage for a market-style collateral swap. The signed sell amount was 50,432,688.41618 aEthUSDT. The signed minimum buying amount was 324.949260918413591035 aEthAAVE. The actual settlement paid 327.241335505966487788 aEthAAVE.

This is an extremely important detail. This order did not expect to gain thousands of AAVE and was then somehow destroyed midway. It was constructed around the expectation of over three hundred AAVE results.

The Complete Link of Routing Collapse

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

The top-level capital flow core relies on the CoW protocol’s 0x9008-prefixed GPv2Settlement settlement contract. First, the 0x60bf-prefixed HooksTrampoline contract completed the aEthUSDT authorization operation, allowing the CoW treasury relayer to extract user assets without separate transaction authorization; subsequently, the 0xc92e-prefixed GPv2VaultRelayer contract extracted 50,432,688.41618 aEthUSDT from the user wallet into the settlement process, and until this point, all operations conformed to normal logic.

The settlement contract then granted aEthUSDT operational authority to an unnamed auxiliary contract starting with 0xd524, and initiated a call using the function selector 0x494b3137; this auxiliary contract then transferred execution authority to an unnamed executor contract starting with 0x699c, completely exposing the full picture of the anomalous transaction routing.

The first valid 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; subsequently, the routing jumps to the Uniswap V3 deep USDT/WETH trading pool, converting all 50,432,688.41618 USDT into 17,957.810805702142342238 WETH.

This stage of the transaction is entirely normal: the exchange rate was about 2808.4 USDT for 1 WETH, in line with market conditions, without liquidity issues, no computation deviations, and no anomalies in the first hop transaction link.

The problem arises in the second jump; once you see the liquidity reserves, the remaining story becomes inevitable.

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

I checked the historical liquidity reserve data for that trading pool just before the anomalous transaction occurred (block height 24643150); the pool held only:

331.631982538108027323 AAVE, 17.653276196397688066 WETH

This is not an error in data entry but a hard fact.

This trading routing injected nearly 17,958 WETH entirely into a minuscule trading pool that only reserves 17.65 WETH, corresponding to a total inventory of only 331.63 AAVE, with the amount of WETH injected being about 1,017 times the pool's WETH reserve.

This is neither a "high slippage" or "slightly thin liquidity" common issue but represents an extremely absurd market order execution path, equivalent to forcing a very small constant product AMM pool to bear a transaction whose scale exceeds its own by thousands of times.

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

The SushiSwap trading pair triggered a core Swap event: the executor transferred in 17,957.810805702142342238 WETH, only swapping back for 331.305315608938235428 AAVE. After completing the transaction, the pool's remaining liquidity was approximately:

0.326666929169791895 AAVE, 17,975.464081898540030304 WETH

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

Based on the reserves before the transaction, the implied price of AAVE in the pool was about 149.50 dollars. The actual execution price for the user was approximately 154,114.66 USDT for 1 AAVE. This differed by over 1,000 times the spot price before the transaction.

Next, these AAVE were supplied back to the Aave liquidity pool using the selector 0x617ba037, that is, supply(address,uint256,address,uint16). As a result, 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 the user's payment.

Therefore, the settlement did not suddenly distort a good execution result into a bad outcome. It simply finalized the result that the routing had already produced.

This is a key point, worth stating clearly: the disastrous result had already been “preset” in the routing before execution.

In the embedded auxiliary contract call data, the target buying amount on the buy side is approximately 331.272185078031026739, the user's signed minimum buying amount is 324.949260918413591035, the actual settled amount is 327.241335505966487788, all core numbers had already locked in the scale of over three hundred AAVE before settlement.

This routing was born faulty.

Where is the vulnerability?

The answer is: every layer of the system's validation mechanism checks the wrong dimension.

All levels only verify whether the transaction is executable, whether the signature is valid, and whether the amount is non-zero, but there is hardly any core level checking whether the transaction routing is economically reasonable; this is the root cause of the mechanism's failure.

Code Defect in Aave Interface Adapter Quoting Path

The first obvious code anomaly occurs in the CoW adapter quoting process on the Aave interface: the function originally used to accompany the adapter’s specific application data when requesting a quote was directly forcefully 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 normally accompany the actual published order. In other words, what was quoted was not entirely what was to be executed. The code comments even state that this helper function's purpose is to make the adapter quotes more precise, yet this function was forcibly disabled.

Weakness in the Reasonability Assessment of CoW Quoting Competition Logic (Core Vulnerability)

The second and most severe problem lies in the CoW protocol's quoting competition logic: in its public service code, as long as the gas fee for the quote 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 "reasonability."

The system did not integrate an oracle for price robustness checks, there were no interception mechanisms for “quotes deviating from the spot price by over 500 times”, no risk assessments for “the route completely draining the liquidity pool”, and no warnings for “the last hop liquidity severely mismatching the order scale”; it merely required the solver to return an executable, non-zero routing scheme, which the system accepted, this is the core vulnerability of this incident.

Flaws in Uniswap V2 Style Liquidity Modeling Logic

The third issue lies in the Uniswap V2 style liquidity pool modeling method: the code only employs the standard constant product algorithm, rejecting mathematically impossible scenarios such as zero reserves, numeric underflows, and reserve overflows, and does not conduct economic feasibility checks.

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

This segment of code does not judge whether the liquidity pool is sufficient to accommodate the corresponding routing transaction; it merely checks whether the swap operation is mathematically valid. Therefore, even a minuscule pool holding only 331 AAVE would be deemed a suitable venue for accepting a buying request of 17,957 WETH, simply because the constant product algorithm can yield a non-zero result, completely ignoring that this result could lead to devastating asset losses.

Flash Loan SDK and Order Verification Mechanism’s Secondary Breakdown

Subsequently, the flash loan SDK directly solidified this invalid quote into the order and hook's 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 at the time of execution. It serialized the already quoted bad amount into the hook data and determined instance addresses. Once a bad quote exists, the remaining mechanisms faithfully pass it along.

Even CoW's order validation logic here did not truly protect the user, as it only checks whether the order exceeds the market price at the time of the quote, without checking the quote itself against actual liquidity for absurdity.

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 indeed have a high price impact warning, but it is not a hard circuit breaker. When the value loss exceeds 20%, it turns into a confirmation checkbox.

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

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

Therefore, even if this transaction would nearly clear the entire asset value, the system only classified it as an operation requiring user confirmation and not as a high-risk transaction that the system must forcibly reject; the warning mechanism completely lost its risk interception function.

Based on all the aforementioned mechanism failures, I absolutely do not agree with the perfunctory conclusion that “this was just a user mistake.” The user did indeed 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” before directly allowing it to proceed, ultimately leading to disastrous consequences.

The Routing Was Not Tampered With

This phase is crucial and directly rules out a lot of erroneous speculations: the Aave official interface process corresponding to aave-v3-interface-collateral-swap will calculate the slippage-adjusted buying amount in the useSwapOrderAmounts.ts file at line 139, considering quotes, network fees, partner fees, and flash loan fees; at line 331, it converts it into the buyAmountBigInt value; then in CollateralSwapActionsViaCoWAdapters.tsx at line 191, it accurately signs this amount.

The subsequent adapter contract will validate at line 141 of AaveV3BaseAdapter.sol, ensuring that the signature order fields match the stored values precisely; the CoW settlement contract will forcibly enforce the signed agreed limit rules at line 337 of GPv2Settlement.sol. Therefore, the on-chain execution results did not exceed the limits allowed by the signed order, and the assets actually received by the user 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 defect in routing had already determined the outcome.

Where Did the Disappearing Value Go?

The next transaction in the same block (hash starting with 0x45388b0f) completed a backrunning arbitrage against the impaired SushiSwap AAVE/WETH pool. After the anomalous transaction stuffed the pool with massive amounts of WETH and drained most of the AAVE, the arbitrageur immediately sold AAVE back into the pool, capturing the surplus value created by the liquidity imbalance.

This backrunning arbitrage extracted approximately 17,929.770158685933 WETH, subsequently paying about 13,087.73 ETH to the block builder and approximately 4,824.31 ETH to the arbitrage execution address.

The entire economic value lost by the user ultimately transformed almost instantly into MEV arbitrage profits within the same block and the block builders’ profits.

Additionally, checking the block-level time sequence confirms: before the transaction, no one maliciously manipulated the SushiSwap trading pool to set a trap for users; the AAVE/WETH trading pair was first touched by this anomalous transaction (transaction index 1); the immediately following next transaction (transaction index 2) targeted the price distortion caused by this transaction for its first backrun; transaction index 3 also touched this trading pair during the market correction process. The clear timeline corroborates: this anomalous transaction created an extreme price distortion, and subsequent transactions directly harvested this distorted gain.

So, whose fault is it?

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

If you ask whether CoW’s GPv2Settlement contract crashed, the answer is no. The settlement enforced a valid signed order and paid an amount higher than the signed minimum.

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

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

The main responsibility lies with CoW protocol's routing, quoting, and solver modules: the entire system’s standard for determining “reasonable routing” is too weak, allowing multimillion dollar orders to ultimately flow to a micro low liquidity pool, simply accepting the routing as executable and non-zero, entirely ignoring the extreme unreasonableness at the economic level.

The secondary responsibility lies with the Aave front-end interface: when requesting adapter quotes, it did not attach the application data related to the hooks, directly passing erroneous results into the signing process, relying solely on warning prompts, with no hard refusal mechanism, which is utterly inadequate to guard against risks for such extreme large transactions.

This represents an extreme failure in transaction routing quality and risk control safeguards, directly transforming a legitimate and compliant collateral rotation operation into a catastrophic asset loss incident.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。