This article is from: @Ehsan1579
Compiled by Odaily Odaily( @OdailyChina ); Translated by Ethan ( @ethanzhang_web3)
Judging from the title alone, one would likely mistakenly believe this is a vulnerability exploitation attack.
The core of the incident is that someone exchanged USDT worth $50.4 million for only $35,900 worth of AAVE.
When I first heard about this, I was truly shocked. Therefore, I thoroughly reviewed the entire incident: transaction tracing, solver paths, contract calls, historical reserves, settlement data, adapter processes, Aave UI code, CoW flash loan SDK, and routing code that determines whether a quote is "reasonable".
This was not a hack. The Aave core protocol was correct. CoW settlement was correct. Uniswap was correct. SushiSwap was correct. Transactions were valid, signatures were valid, and all contracts executed strictly according to the code. Yet, almost all economic value was destroyed simply because the route it was allowed to take was utterly absurd.
The public blockchain itself isn't the problem; the problem lies with the routing.
In my view, simply attributing this incident to a "user error" is neither objective nor rigorous. While the user did complete the order signing, the entire software system allowed an operation involving nearly $50 million in collateral rotation to go through the entire process of quoting, signing, routing planning, and execution, all directed to a low-liquidity pool holding only about 331 AAVE tokens. This should have been completely impossible; at the very least, it should have been forcefully blocked and rejected by the system before settlement even began.
Transaction core information traceability
The hash of this abnormal transaction is 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f. It was confirmed on March 12, 2026, at Ethereum mainnet block height 24643151. The transaction index is 1, it consumed 3,780,570 Gas units, and the transaction was successfully executed. The wallet address to which the order belongs starts with 0x98b9, and the address of the solver (transaction sender) that actually executed the transaction starts with 0x3980, which is marked as tsolver in the CoW competition data.
First, it's important to understand that this isn't a simple wallet-level USDT to AAVE exchange. The tokens sold are aEthUSDT, which are USDT deposit certificates earning interest on the Aave platform. The tokens bought are aEthAAVE, which are AAVE deposit certificates earning interest on the Aave platform. Therefore, this is actually an Aave collateral rotation 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 had only 4.980399 aEthUSDT remaining and received 327.241335505966487788 aEthAAVE. In effect, the wallet sold almost its entire position.
The metadata more clearly indicates that the route was already "toxic" before execution. The order originated from the aave-v3-interface-collateral-swap process. The CoW API displays it as a signed sell order, while the application metadata marks it as a market-based 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 out 327.241335505966487788 aEthAAVE.
This is an extremely important detail. This order wasn't originally intended to yield tens of thousands of AAVEs, and then it was inexplicably destroyed midway through its construction. It was built around the expected outcome of just over three hundred AAVEs.
The complete link of the routing failure
Once you follow the trade trail, the whole process becomes brutally straightforward.
The core of the top-level fund transfer relies on the GPv2Settlement settlement contract starting with 0x9008 in the CoW protocol. First, the HooksTrampoline contract starting with 0x60bf completes the aEthUSDT authorization operation, allowing the CoW vault relayer to withdraw user assets without separate transaction authorization. Subsequently, the GPv2VaultRelayer contract starting with 0xc92e extracts 50,432,688.41618 aEthUSDT from the user's wallet and enters the settlement process. Up to this stage, all operations are in accordance with normal logic.
The settlement contract then grants the aEthUSDT operation rights to a non-open-source auxiliary contract starting with 0xd524, and initiates a call through the function selector 0x494b3137; the auxiliary contract then transfers the execution rights to a non-open-source executor contract starting with 0x699c. At this point, the full picture of the abnormal transaction routing is completely exposed.
The first valid call points to the Aave liquidity pool contract starting with 0x87870, which destroys aEthUSDT through the withdraw function (selector 0x69328dec) and redeems the underlying native USDT. Subsequently, the route jumps to the Uniswap V3 depth USDT/WETH trading pool starting with 0x4e68, exchanging all 50,432,688.41618 USDT for 17,957.810805702142342238 WETH.
The transactions in this phase were completely normal: the exchange rate was approximately 2808.4 USDT to 1 WETH, which was in line with the market conditions at the time. There were no liquidity issues, no calculation errors, and no abnormalities in the first hop of the transaction chain.
The problem lies in the second jump; once you see the liquidity reserves, the rest of the story is inevitable.
After acquiring 17957.810805702142342238 WETH, the executor transferred all funds to the SushiSwap V2 AAVE/WETH trading pool at address 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.
I checked the historical liquidity reserve data of this trading pool at the moment before the abnormal transaction occurred (block height 24643150), and the pool only held:
331.631982538108027323 AAVE, 17.653276196397688066 WETH
This is not a data entry error, but an undeniable fact.
This transaction route injected nearly 17,958 WETH into a micro-transaction pool with a reserve of only 17.65 WETH, corresponding to a total AAVE inventory of only 331.63 WETH. The amount of WETH input was approximately 1017 times the WETH reserve in the pool.
This is by no means a conventional problem of "high slippage" or "slightly thin liquidity," but rather an extremely absurd market order execution path, which is equivalent to forcing a very small constant product AMM pool to take on a huge transaction that is thousands of times larger than itself.
The AMM trading pool executed operations according to the established algorithm, nearly exhausting all of the pool's AAVE reserves.
The SushiSwap trading pair triggered a core Swap event: the executor transferred 17957.810805702142342238 WETH, exchanging it for only 331.305315608938235428 AAVE. After the transaction, the remaining liquidity in the pool is approximately:
0.326666929169791895 AAVE, 17975.464081898540030304 WETH
To put it bluntly, about 99.9% of the AAVE inventory in the pool was drained in one jump.
Based on pre-trade reserves, the implied AAVE price in the pool was approximately $149.50. The user's actual execution price was approximately 154,114.66 USDT to 1 AAVE. This is more than 1000 times lower than the pre-trade spot price.
Next, these AAVE are supplied back to the Aave pool using selector 0x617ba037, i.e., supply(address, uint256, address, uint16). The result is that newly minted aEthAAVE is sent back to the settlement contract. The settlement contract ultimately transfers 327.241335505966487788 aEthAAVE to the user. Approximately 4.06398010297174764 aEthAAVE remain in the settlement contract as a surplus relative to the user's payment.
Therefore, the settlement did not suddenly distort a good execution result into a bad one. It simply finalized the result that the routing had already produced.
This is the key point, and it's worth stating clearly: The disastrous outcome is "preset" before the routing is even executed.
In the auxiliary contract call data embedded in the router, the target amount for the purchase end is approximately 331.272185078031026739 AAVE, the minimum purchase amount agreed upon by the user signature is 324.949260918413591035 AAVE, and the actual settlement amount is 327.241335505966487788 AAVE. All core values were locked at around three hundred AAVE before settlement.
This route was inherently flawed.
Where is the vulnerability?
The answer is: each layer of the system's verification mechanism checks for errors.
All levels only verify whether the transaction is executable, whether the signature is valid, and whether the amount is non-zero, but there is almost no core level to verify whether the transaction route is economically reasonable. This is the core root cause of the mechanism's failure.
Aave UI adapter pricing path code defect
The first obvious code anomaly appears in the CoW adapter quoting process in the Aave interface: the function that was originally used to attach adapter-specific application data when requesting a quote has been forcibly disabled.
Sources: rates.helpers.ts:93 and adapters.helpers.ts:194
This means that when the Aave interface requests a quote from the CoW, it doesn't include the flash loan and hook metadata that would be attached when the order is actually published . In other words, what's being quoted isn't necessarily what's being executed. The code comments even state that the purpose of this helper function is to make the adapter's quote more accurate, yet this function is hard-disabled.
The rationality of the CoW bidding competition logic is too weak (core vulnerability).
The second and most serious problem lies in the bidding competition logic of the CoW protocol: in its public service code, as long as the quoted gas fee is positive and the output amount is not zero , it will be judged as a "reasonable bid".
Source: quote.rs:31
This is a shockingly weak definition of "reasonableness" for a routing system that processes eight-figure orders.
The system lacks oracle verification for price integrity, has no interception mechanism for "quotes deviating from spot prices by more than 500 times", no risk assessment that "routes will completely drain the liquidity pool", and no warning that "last hop liquidity is severely mismatched with order size". The system accepts any executable, non-zero routing solution returned by the solver, which is the core vulnerability of this incident.
Deficiencies in Uniswap V2-like liquidity modeling logic
The third issue lies in the Uniswap V2 style liquidity pool modeling approach: the code only uses the standard constant product algorithm, rejecting only mathematically impossible situations such as zero reserves, numerical underflow, and reserve overflow, without performing economic feasibility checks.
Source: pool_fetching.rs:118 and pool_fetching.rs:153
This code snippet does not determine whether the liquidity pool size is sufficient to handle the corresponding routed transactions; it only checks whether the exchange operation is mathematically valid. Therefore, even a tiny pool holding only 331 AAVE would be considered a valid venue to handle a buy request for 17,957 WETH, simply because the constant product algorithm can calculate a non-zero result, completely ignoring the devastating asset loss this result would cause.
The second failure of the flash loan SDK and order verification mechanism
Subsequently, the Flash Loan SDK directly embedded this invalid quote into the execution payload of the order and hook without performing any secondary risk interception.
then:
Source: index.js:484 and index.js:591
This is why I've always said this route is "born bad." The adapter layer doesn't "discover" a new bad amount during execution. It serializes the already quoted bad amount into the hook data and the defined instance address . Once a bad quote exists, the rest of the mechanism faithfully passes it on.
Even CoW's order verification logic doesn't really protect users here, because it only checks whether the order exceeds the market price at the time of the quote, without checking whether the quote itself is absurd relative to actual liquidity.
Source: order_validation.rs:694
This is a consistency check. Even if the quote itself is nonsensical, the order can still be approved.
The UI front-end warning mechanism is practically useless.
The Aave interface does display a high price shock warning, but it 's not a hard circuit breaker . When the value loss exceeds 20%, it becomes a confirmation checkbox.
Once the user checks the checkbox, the obstacle is cleared:
Sources: helpers.ts:24 and HighPriceImpactWarning.tsx:35
Therefore, even if this transaction would wipe out almost all asset value, the system would only classify it as an operation that requires user confirmation, rather than a high-risk transaction that the system must forcefully reject. The warning mechanism would completely lose its risk interception function.
Given the failure of all the above mechanisms, I absolutely disagree with the dismissive conclusion that "this was just a user making a 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, directly allowing the process after determining that it was "non-zero, executable, and signed," ultimately leading to disastrous consequences.
The route has not been tampered with
This step is crucial, directly eliminating a large number of incorrect guesses: the official Aave interface process corresponding to aave-v3-interface-collateral-swap calculates the slippage-adjusted buy amount in line 139 of the useSwapOrderAmounts.ts file, taking into account the quote, flash loan fees; line 331 converts it to the buyAmountBigInt value; and then, in line 191 of the CollateralSwapActionsViaCoWAdapters.tsx file, the amount is precisely signed.
The adapter contract will verify a perfect match between the signed order field and the stored value on line 141 of the AaveV3BaseAdapter.sol file; the CoW settlement contract will enforce the limit rules of the signature agreement on line 337 of the GPv2Settlement.sol file. Therefore, the on-chain execution result did not exceed the range allowed by the signed order, and the assets actually received by the user were even higher than the minimum limit stipulated in the signature agreement.
This is sufficient proof that the disaster occurred before the settlement process, not during the settlement process; the fatal flaw in the routing had already sealed the fate of the disaster.
Where did the lost value go?
The next transaction within the same block (starting with hash 0x45388b0f) completed a back-run arbitrage against the corrupted SushiSwap AAVE/WETH pool. After the anomalous 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, reaping the excess value brought about by the liquidity imbalance.
This arbitrage operation yielded approximately 17,929.770158685933 WETH, of which approximately 13,087.73 ETH were subsequently paid to the block builder and approximately 4,824.31 ETH were paid to the arbitrage execution address.
The entire economic value lost by users is ultimately converted almost instantly into MEV arbitrage profits and block builder profits within the same block.
Furthermore, checking the block-level timeline confirms that: no one maliciously manipulated the SushiSwap trading pool to trick users before the transaction; the first time the AAVE/WETH trading pair was touched was in this abnormal transaction (transaction index 1); the next transaction (transaction index 2) completed the first reversal of the price distortion caused by this transaction; transaction index 3 also touched the trading pair during the market correction process. The timeline clearly demonstrates that this abnormal transaction created an extreme price distortion, and subsequent transactions directly harvested the profits from this distortion.
So, whose fault is it?
If you ask whether the Aave V3 core protocol has crashed, the answer is no . The Aave liquidity pool executes its operations exactly as instructed, completing the USDT redemption and AAVE deposit process normally.
If you ask whether the CoW's GPv2Settlement contract crashed, the answer is no . Settlement enforced a valid signed order and paid an amount exceeding the minimum signature requirement.
If you ask whether the trading pairs in Uniswap V3 or SushiSwap have crashed, the answer is also no . Both trading pools price trades according to their own algorithmic rules.
True systemic failures occur at higher levels of routing and risk control:
The main responsible party is the routing, pricing, and solver module of the CoW protocol : the entire system has too weak a standard for judging "reasonable routing", allowing huge orders of tens of millions of dollars to flow to micro-liquidity pools. As long as the route is executable and non-zero, it is accepted, completely ignoring the extreme irrationality at the economic level.
The secondary responsible party is the Aave front-end interface : when requesting an adapter quote, it did not include the application data associated with the hook, directly passed the erroneous result to the signature process, and relied solely on warning prompts without a hard rejection mechanism. For such extremely large transactions, this type of risk control measure is completely insufficient to prevent risks.
This was an extreme failure in the quality of transaction routing and risk control, which directly turned a legal and compliant collateral rotation operation into a devastating asset loss event.
