50 MILLION USDDT FOR $35,000 AAVE: HOW DID THE DISASTER HAPPEN? WHO SHOULD WE BLAME

This post is from:

Compile Odaily Daily Planet@OdailyChina); Translator Ethan()@ethanzhang web3)

Looking at the title of the incident alone, the probability is that the attack would be mistaken for a loophole。

The core of the event was:THE USDT, VALUED AT $50.4 MILLION, WAS EVENTUALLY CONVERTED TO AAVE ONLY, VALUED AT $359 MILLION。

I was shocked when I first heard about it. So I completely combed the whole thing: transaction tracking, solver paths, contract calls, historical reserves, clearing data, adaptor processes, Aave interface code, CoW Flash loan SDK, and routing codes to determine whether the offer is “reasonable”。

This is not a hacker attack。Aave's core agreement didn't go wrong. There was no error in the COW settlement. Uniswap didn't make a mistake. SushiSwap made no mistake. The transaction is valid, the signature is valid and all contracts are performed in strict code. However, almost all economic values have been destroyed, simply because the path it is allowed to follow is absurd to the extreme。

There's nothing wrong with the chain, it's the path。

IT SEEMS TO ME THAT UNDERESTIMATING THE MATTER AS A SIMPLE “USER ERROR” IS NOT AN OBJECTIVE AND STRICT ATTITUDE. IT IS TRUE THAT THE USER HAS COMPLETED THE SIGNATURE OF THE ORDER, BUT THE ENTIRE SOFTWARE SYSTEM ALLOWS FOR AN OPERATION INVOLVING ALMOST $50 MILLION IN COLLATERAL ROTATION, THE COMPLETION OF QUOTATIONS, SIGNATURES, ROUTE PLANNING UNTIL FINAL EXECUTION, AND THE ENTIRE PROCESS POINTS TO A LOW-MOBILITY POOL WITH ONLY ABOUT 331 AAVES. THIS SHOULD HAVE BEEN COMPLETELY IMPOSSIBLE, AT LEAST BEFORE THE SETTLEMENT CHAIN HAD BEEN INITIATED, AND IT SHOULD HAVE BEEN REJECTED BY THE SYSTEM。

Transaction core information trace

This unusual transaction, Hashi: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff7ff5139f3492ce430801f, was confirmed on March 12, 2026 at the height of the main area of the Taifeng Network at 24643151, with a trading index of 1 and a consumption of 3780570 units. The purchase order belongs to the wallet at the beginning of 0x98b9, the solver (transaction sender) that actually executes the transaction at the beginning of 0x3980 and is marked as tsolver in the CW competition data。

First of all, it's not a simple wallet level USDT to AAVE exchange. Selling tokens is aEthusDT, an interest-bearing USDT deposit certificate on the Aave platform. The purchase of a token is an EthaAVE, an AAVE deposit certificate that yields interest on the Aave platform. So this is actually a rotation of Aave collateral through the CW settlement system and its flash loan adapter process。

Before the transaction, the wallet held approximately 50,432,693.07254 aEthUSDT and 0 aEthAAVE. After the transaction, only 4.980399 aEthUSDT was left and 327.241335559664878 aEthAAVE was received. In fact, the wallet sold almost all the positions。

The metadata show more clearly that the route was “toxic” before implementation. The order comes from aave-v3-interface-collar-swap process. CoW 's API displays it as a signed sales order, while applying metadata labels it as a marketable collateral swap using 121 basis points. The amount signed was 50,432,688.41618 aEthUSDT. The minimum purchase value for signatures was 324.949260918413591035 aEthAAVE. The actual settlement paid 327.24133555966487788 aEthAAVE。

THAT IS AN EXTREMELY IMPORTANT DETAIL. THE ORDER WAS NOT EXPECTED TO RECEIVE TENS OF THOUSANDS OF AAVES AND WAS THEN DESTROYED IN THE MIDDLE OF NOWHERE. IT WAS BUILT AROUND 300 OR SO AAVE AT THE BEGINNING。

A complete link to the crash

Once you follow the deal, the whole process is brutal and straightforward。

The top-level fund flow core relies on the GPv2Settlement settlement contract starting with the CW agreement 0x9008. First, the HooksTrampoline contract starting with 0x60bf completes aEthUSDT authorization to allow the CW Treasury repeater to extract the user ' s assets without a separate transaction authorization; then the GPv2VaultRelayer contract starting with 0xc92e extracts 50432688.41618 aEthUSDTs from the user ' s wallet into the settlement process, and as of this point all operations are in line with normal logic。

The settlement contract then grants aEthUSDT operating privileges to an open source auxiliary contract beginning with 0xd524 and initiates a call through the function selector 0x494b3137; the auxiliary contract then transfers the enforcement authority to an open source implementer contract starting with 0x699c, where the full picture of the route of the unusual transaction is exposed。

The first effective call to the Aave pool contract, starting with 0x87870, destroys aEthUSDT by means of the indraw function (optionor 0x69328dec) and redeems USDT, the Uniswap V3 depth USDTT/WETH trading pool, which is then transferred by jump to 0x4e68 and converts all 50432688.41618 USDTs to 17957.8808057021422338 WETH。

THE TRANSACTIONS AT THIS STAGE WERE PERFECTLY NORMAL: THE EXCHANGE RATE WAS ABOUT 2808.4 USDT TO 1 WETH, WHICH WAS CONSISTENT WITH MARKET CONDITIONS AT THE TIME, WAS FREE OF LIQUIDITY PROBLEMS, HAD NO ARITHMETICAL DEVIATION, AND THERE WAS NO ANOMALY IN THE FIRST JUMP CHAIN。

The problem is, once you see the liquidity reserve, the rest of the story is inevitable。

Upon acquisition of 17957.8108057024242238, all funds were transferred to the SushiSwap V2 AAVE/WETH trading pool at the address of 0xd75ea151a61d06868e318988d28dfe5d9df57b4。

I checked the historical liquidity data of the trading pool at the moment prior to the unusual transaction (the height of the block 24643150) and only held:

331.63 1982 5381080273 AAVE 17.653276 1963 997688066 WETH

This is not a data entry error, but an iron fact。

THIS TRADE ROUTE, NEARLY 17958 WETHS WERE ALL INJECTED INTO A MICRO-TRADING POOL WITH A STOCK OF ONLY 17.65 WETHS, CORRESPONDING TO THE TOTAL STOCK OF AAVE OF ONLY 331.63, AND THE AMOUNT OF WETHS ENTERED WAS APPROXIMATELY 1017 TIMES THE AMOUNT OF THE WETH RESERVES IN THE POOL。

THIS IS BY NO MEANS A ROUTINE PROBLEM OF “HIGH SLIDE POINTS” OR “SLIGHT LIQUIDITY”, BUT AN EXTREMELY ABSURD PATH TO THE IMPLEMENTATION OF A MARKET LIST, WHICH IS TANTAMOUNT TO FORCING A VERY SMALL, CONSTANT PRODUCT OF THE AMM POOL TO CARRY ON A HUGE DEAL THAT IS THOUSANDS OF TIMES LARGER THAN ITS OWN。

THE AMM TRADING POOL WAS OPERATED IN ACCORDANCE WITH THE ESTABLISHED ALGORITHM AND NEARLY DEPLETED ALL AAVE RESERVES IN THE POOL。

SushiSwap transaction to trigger the core Swap exchange: the implementer transferred to 17957.810805702142342238 WETH and only returned 331.30531568938235428 AAVE. Upon completion of the transaction, the remaining liquidity of the pool is approximately:

0.326666929169791895 AAVE, 17975.46418898540030304 WETH

TO BE HONEST, ABOUT 99.9% OF THE AAVE STOCK IN THE POOL WAS DRAINED IN ONE JUMP。

BASED ON THE PRE-TRANSACTION RESERVE, THE POOL IMPLIED AN AAVE PRICE OF APPROXIMATELY US$ 149.50. THE ACTUAL EXECUTION PRICE OF THE USER IS APPROXIMATELY 154,114.66 USDT TO 1 AAVE. THAT'S MORE THAN 1,000 TIMES THE SPOT PRICE BEFORE THE DEAL。

These AAVEs are then supplied back to the Aave fund pool, using a choicer 0x617ba037, which is subply (adadress, uint256, advice, uint 16). As a result, the newly forged aEthAAVE was sent back to the settlement contract. The settlement contract eventually transferred 327.241335559664878 aEthAAVE to the user. Approximately 4.0639801029717764 aEthAAVE remained in settlement contracts as a surplus paid relative to the user。

Thus, the settlement did not suddenly distort a good performance result into a bad one. It is only the result of the finalization of the route that has long been produced。

And that's the key point, and it's worth saying clearly: catastrophic results are pre-set before route execution。

THE PURCHASE END VALUE IS APPROXIMATELY 331.272185078031026739, THE MINIMUM PURCHASE VALUE AGREED FOR THE USER SIGNATURE IS 324.94926091841591035 AND THE ACTUAL SETTLEMENT AMOUNT IS 327.24133555966487888, AND ALL CORE VALUES ARE LOCKED IN THE ORDER OF 300 AAVES BEFORE SETTLEMENT。

This path was born bad。

Where's the loophole

The answer is that the verification mechanism at every level of the system is verifying the dimensions of the error。

All levels verify only whether the transaction is executed, whether the signature is valid or not and whether the amount is not zeroThere is little core level to verify the legitimacy of trade routes at the economic level, which is the core cause of institutional failures。

The code defect for the interface adapter quote path for Aave

The first obvious code anomaly appears in the CW adapter quote process in the Aave interface: the function that was originally used for requesting quotations with the exclusive application data of the adapter is directly disabled。

Source:i'm sorry, i'm sorryandi'm sorry

This means that the Aave interface is asking for quotations from the CoWIt's not accompanied by lightning and hook metadata that will be attached to actual ordersI don't know. In other words, what is quoted is not exactly what is to be executed. The code note even states that the assistant function is designed to make the adaptor's offer more precise, and then the function is severely disabled。

CoW Reasonability of the price logic is too weak (core gap)

The second and most serious problem is the competitive logic of the CoW protocol: in its public service code, it's not the only one that's going to make itAs long as the offer is positive and not zeroIt is determined that it is a “reasonable offer”。

Source:quote.rs:31

For an eight-digit routing systemIt's an alarming weaknessThe definition of “reasonableness”。

The system does not have access to the prognosis machine for price soundness verification, there is no interception mechanism for "price deviations from spot prices more than 500 times" and there is no risk that "routing will drain the mobility pool completely" and there is no warning that "the last jump of mobility will be severely out of proportion to the size of the order"; only the demanufactor is required to return to an implementable, non-zero router, and the system is acceptedThis is the core loophole of this event。

Deficiencies in the liquid modelling logic of Uniswap V2

The third problem is the Uniswap V2-style liquid pool modelling: the code uses only standard constant product algorithms, rejectes only the impossibility of a mathematical level of zero reserves, values-downs, reserves-outs, etc., without validation of economic feasibility。

Source:photo from flickr page of the website: 118andphoto from flickr page of pool meeting.rs:153

THE CODE DOES NOT JUDGE WHETHER THE LIQUID POOL VOLUME IS SUFFICIENT TO CARRY THE CORRESPONDING ROUTE TRANSACTION, BUT ONLY WHETHER THE EXCHANGE OPERATION IS MATHEMATICALLY EFFECTIVE. THUS, EVEN A SMALL POOL WITH A STOCK OF 331 AAVES WOULD BE CONVICTED OF BEING A VALID SITE TO TAKE OVER 17957 WETHS, WHICH COULD ONLY BE CALCULATED AS A NON-ZERO RESULT BY A CONSTANT MULTIPLIER ALGORITHM, WITHOUT REGARD FOR THE DEVASTATING LOSS OF ASSETS。

FLASH LOAN, SDK, AND THE ORDER VALIDATION MECHANISM'S SECONDARY FAILURE

SUBSEQUENTLY, THE FMC SDK FIXED THE INVALID OFFER DIRECTLY INTO THE PERFORMANCE LOAD OF THE ORDER AND HOOK, WITHOUT ANY SECONDARY RISK INTERCEPTION。

Then:

Source:i don't knowandi'm not sure i'm going to be able to do this

That is why I keep saying that this route is “born and bad”. Adapter LayerNot reallyA new bad amount was found at the time of implementation. It's..Sequence of quoted bad amounts to hook data and identified case addresses MediumI don't know. Once a bad offer existed, the remaining mechanisms would pass it on faithfully。

Even COW's order validation logic hereNo real user protectionThis is because it only checks whether the order exceeds the market price at the time of the offer, and not whether the offer itself is absurd in relation to actual liquidity。

Source:order validation.rs: 694

It's a consistency check。If the offer itself is already fabricated, the order can still be made。

UI FRONT END EARLY WARNING MECHANISM IS A DEAD END

Aave does have a high price shock warning on the interface, but..It's not a rigid melting switchI don't know. When value losses exceed 20%, it becomes a confirmation check box。

Once the user ticks the check box, the barrier is removed:

Source:heres.ts: 24andHighPriceImpactWarning.tsx:35

As a result, even if the transaction would close to emptying the full value of the asset, the system would only qualify it as a user-identified operation, rather than a high-risk transaction that the system would have to strongly reject, and the early warning mechanism would have lost its risk interception function altogether。

On the basis of all the above-mentioned failures, I do not agree with the pretentious conclusion that “it is just the user being stupid”. The user did complete the signature, but there were several opportunities for the entire software system to intercept the disaster, but each layer was only subjected to a basic check, and was released directly after a “non-zero, enforceable, signed” decision, with the ultimate result。

The route has not been altered

This link is crucial and directly precludes a number of false speculations: the Aave-v3-interface-collar-swap official interface process, which calculates the value of a slide point adjustment in line 139 of the useSwapOrderAmounts.ts document, together with price quotations, network fees, partner fees, flash loan charges; line 331 converts it to a buyAmountBigInt value; and subsequently, in line 191 of the CollateralSwapactionsViaCoWadapsters.tsx document, the precise signature of the amount is completed。

The successor adaptor contract will be in line 141 of the AaveV3BaseAdapter.sol file, the verification of signature order fields will be fully matched with stored values, and the CoW settlement contract will be in line 337 of the GPv2Settlement.sol document, enforcing the agreed limit rules for signatures. Thus, chain execution results do not go beyond what is permitted by signature orders and the assets actually received by the user are even above the minimum threshold agreed upon for signature。

This is sufficient proof that the disaster occurred before the settlement, not during the settlement process, and that the fatal defects of the route had long been doomed。

Where's the missing value

The next trade in the same block (starting with Hashi 0x45388/b0f) was completed for the damaged SushiSwap AAVE/WETH pool. Once the unusual trade was filled with a huge amount of WETH, and the vast majority of AAVE was drained, the arbitragers immediately sold AAVE back to the pool, where the excess value of harvesting imbalances。

THIS RUNOFF ARBITRAGE WAS TO EXTRACT ABOUT 17929.77015885933 WETHS AND THEN TO PAY ABOUT 13087.73 ETHS TO THE BLOCK BUILDER AND ABOUT 4824.31 ETHS TO THE ARBITRAGE EXECUTION ADDRESS。

THE FULL ECONOMIC VALUE LOST BY THE USER EVENTUALLY TRANSLATES ALMOST INSTANTANEOUSLY INTO MEV ARBITRAGE AND BLOCK BUILDER GAINS WITHIN THE SAME BLOCK。

In addition, the verification block time series confirms that there was no malicious manipulation of the SushiSwap trading pool prior to the transaction, and that the AAVE/WETH transaction was first touched, that is, this unusual transaction (the transaction index 1); that the next transaction immediately followed (the transaction index 2) completes the first runback against price distortions caused by the transaction; and that the transaction index 3 also touches the transaction pair during market restoration. Timelines clearly confirm that this unusual transaction creates extreme price distortions and that subsequent transactions directly capture this distortion。

So whose fault is it

If you ask Aave V3 if the core protocol crashed, the answer is:NothingI don't know. Aave's pool is fully operational according to the instructions and normally completes the USDT foreclosure and AAVE deposit process。

If you ask COW if the contract has collapsed, the answer is:NothingI don't know. The settlement enforced a valid signature order and paid more than the minimum amount of the signature。

If you ask Uniswap V3 or SushiSwap whether the deal crashed, the answer is the sameNothingI don't know. Both types of pools complete transaction pricing according to their own algorithm rules。

The real systemic failure occurred at a higher level of route and wind control:

Routes, quotations and solvers modules for the CW protocol by the main responsible partyThe entire system's criteria for determining “reasonable route” are too weak, allowing tens of millions of United States dollars to be placed in large orders and eventually to flow to a micro, low-mobility pool, which is accepted as long as the route is implementable and non-zero, with complete disregard for the extreme irrationality of the economic dimension。

The secondary liable party is the front line of Aave Noodles: Requests for adapter quotations are made without hook-linked application data, the result of the error is passed directly into the signature process and is based solely on early warning alerts, no rigid rejection mechanism. For such extremely large transactions, such controls are not sufficient to protect against risk。

It was an extreme failure of the quality of the trade route and the extreme nature of the wind fence, which directly rotated a legally compliant collateral into a devastating loss of assets。