Loading Search...
In this article, we explore the entire AAVE swap incident where a trader lost $50M and what we can learn from the event.
Author: Sahil Thakur
On 12 March 2026, a user made a swap through the Aave web interface. The trade converted 50,432,688.41618 aEthUSDT, worth about $50.43 million, into just 327.2413 aEthAAVE, worth about $37,700. All of this happened in one confirmed on-chain transaction.
This was not a hack of the Aave lending protocol. Instead, it was a severe trading failure. The user sent a huge order into a market with very little liquidity. At the same time, MEV bots reacted around the trade. As a result, a sandwich-style sequence in the same block made the outcome even worse.
On the technical side, the transaction settled through CoW Protocol’s settlement contract, GPv2Settlement. The route moved through several steps. First, it went from Aave’s interest-bearing USDT deposit token to regular USDT. Then it moved through a Uniswap V3 USDT/WETH pool. After that, it went into a SushiSwap WETH/AAVE pool with very low liquidity. Finally, the result went back into Aave as aEthAAVE.
In the same block, a bot used a large flash loan from Morpho. It also paid a huge order-flow or block-ordering payment to Titan Builder. That bot captured millions of dollars in value. Meanwhile, the user received only a tiny amount of aEthAAVE.
Public post-mortems from Aave and CoW Protocol say the main cause was price impact from illiquid routing. However, CoW Protocol also pointed to infrastructure and auction problems. According to its account, those issues stopped better routes from reaching the user. They included a hardcoded gas ceiling for quote verification and failures by solvers during execution.
Afterward, Aave announced Aave Shield and started rolling it out. This safeguard works inside the web interface. By default, it blocks swaps with more than 25% price impact. Still, users can turn that protection off in Settings.
As far as public statements and on-chain evidence show, the swap cannot be reversed. So, the loss itself is not recoverable through the blockchain. Any recovery would depend on voluntary refunds or private negotiations. At most, the user might receive back some interface-collected fees, if they verify their identity and make contact. Still, most of the value has already moved to other on-chain participants, including liquidity pools, MEV searchers, and the block builder that received payment.
The main event is visible on-chain through Etherscan.
The user’s swap transaction hash was 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f. It happened in block 24643151.
The timestamp was 12 March 2026, 06:23:23 PM UTC. The transaction came from the user wallet 0x3980dAA7EaaD0B7e0C53cFc5c2760037270DA54D. It went to CoW Protocol’s GPv2Settlement contract at 0x9008D19f58AAbD9eD0D60971565AA8510560ab41.
In that swap, the user traded 50,432,688.41618 aEthUSDT for only 327.2413 aEthAAVE.
Etherscan showed that as roughly $50.43 million turned into about $37,700.
Aave later made it clear that its lending protocol was not hacked or compromised. Instead, the user moved ahead with a quote that already showed an extreme price impact. So, the main problem was not a protocol failure. It was the route itself.
The trade went into markets that did not have enough liquidity for an order that large. CoW Protocol’s post-mortem broadly agreed on that point.
However, CoW also said other problems made the result even worse. According to that account, infrastructure limits and solver failures stopped better routes from reaching the user.
Key on-chain details from the Aave swap incident
The input asset was aEthUSDT.
This is an Aave V3 interest-bearing deposit token.
It represents USDT that a user had supplied to Aave on Ethereum.
Its token contract is 0x23878914efe38d27c4d67ab83ed1b93a74d4086a.
Next, the user’s wallet sent the transaction to CoW Protocol’s settlement contract, GPv2Settlement.
The swap traded 50,432,688.41618 aEthUSDT for 327.2413 aEthAAVE.
So, the transaction did not go straight from one token to another in a simple swap.
Instead, it followed a routed path through multiple steps.
Then, the aEthUSDT had to be turned back into regular USDT.
Etherscan’s decoded transaction shows that the aToken was burned.
At the same time, the underlying USDT was withdrawn from Aave.
This step matters because decentralized exchanges do not trade the Aave deposit token directly in the same way.
So, the swap first had to unwrap that position into standard USDT.
After that, the USDT moved into a Uniswap V3 pool.
On-chain transfers show that 50,432,688.41618 USDT went in.
In return, the route produced 17,957.8108 WETH.
That WETH then moved to the next venue.
This part already showed major execution damage.
Before the final step even happened, about $50 million in USDT had become only about $38 million to $39 million in WETH.
That estimate comes from the ETH reference pricing shown on Etherscan at the time.
So, the trade had already lost a huge amount of value before the last hop.
Next, the 17,957.8108 WETH went into a SushiSwap AAVE liquidity pool at 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.
That pool returned only 331.3053 AAVE.
After that, the AAVE was deposited back into Aave.
In the end, the user received 327.2413 aEthAAVE after additional movements and fees.
This was the key failure point.
Multiple analyses say the final pool had only tens of thousands of dollars in liquidity at the time.
So, it was nowhere near deep enough for a swap of that size.
A trade worth roughly $37 million could not pass through that pool cleanly.
Instead, the order pushed the price higher and higher as it moved through the pool.
That is why the final result became so extreme.
Beginners often hear the word “slippage” and use it to describe everything.
However, it helps to separate two ideas.
Slippage tolerance is the maximum difference a user agrees to accept between the quoted amount and the final executed amount.
In many systems, this appears as a minimum received amount or a limit price.
Price impact is different.
It is the damage caused by the trade itself when the order is too large for the available liquidity. In that case, the trade moves the market while it is being executed.
Aave’s post-mortem stressed this point.
The quote already showed extreme price impact before the trade even executed. So, the problem was not only what happened during execution. The quote itself was already very bad.
In this case, the evidence suggests that the user accepted a very low minimum output. The final on-chain result supports that view.
As a result, the trade was allowed to go through even though the route produced an extremely poor price.
The same block also included a highly profitable MEV transaction tied to the swap. The MEV transaction hash was 0x45388b0f9ff46ffe98a3124c22ab1db2b1764ecb3b61234e29e5c9732b7fd4ab.
Etherscan labels it as an aggregated swap across multiple tokens and venues, including Bancor and SushiSwap. It is linked to an MEV bot address: 0x06CFf7088619C7178F5e14f0B119458d08d2f5ef. The bot used a flash loan of 14,175.7071 WETH from Morpho.
Then it acquired AAVE. After that, it sold AAVE into SushiSwap for 17,929.7702 ETH. It also paid 13,087.7326 ETH to Titan Builder for block ordering.
Meanwhile, it sent 4,824.3176 ETH to its own funding address.
In simple terms, the bot positioned itself around the user’s trade and captured value from the price distortion. That value did not disappear. Instead, it moved to other participants in the block.
Independent analysis from Coin Metrics supports that view.
It says a large share of the outcome came from MEV extraction and payments to the block builder in the same block.
So, this incident was not just about a bad swap route.
It was also about how other on-chain actors captured value once that bad route was exposed.
he victim swap and the MEV transaction share the same on-chain timestamp because both were included in the same block.
Aave’s public explanation focused mainly on illiquid market conditions. It said the core lending protocol was not at risk and that the incident did not come from a protocol exploit. Instead, Aave described it as a bad execution outcome. According to Aave, the user accepted a quote that already showed extreme price impact. So, Aave’s main point was simple: the protocol itself was not compromised, but the trade was routed into liquidity that was too shallow.
Aave also announced a new interface safeguard called Aave Shield. This feature was introduced to reduce the chance of similar user mistakes. At the same time, Aave said the interface had already shown clear risk warnings, but the user still moved forward with the swap. Public sources did not identify the user. Stani Kulechov also posted about the incident and pointed people to Aave’s post-mortem explanation.
CoW Protocol described the incident in a more complex way. It agreed that illiquidity was a major problem, but it also said other failures made the result worse. According to public reporting based on CoW’s post-mortem, better routes may have existed, yet those routes allegedly did not reach the user.
CoW said one reason was a quote verification system with a legacy gas ceiling. That system allegedly rejected some better routes. In addition, a solver that won auctions with better execution paths allegedly failed to submit transactions. As a result, a worse route ended up filling the order.
CoW also raised another concern. It suggested the private transaction may have leaked. The victim transaction showed an Etherscan note saying it was confirmed within 30 seconds. CoW linked that detail to possible public mempool exposure. If that happened, MEV bots may have had a better chance to react to the trade.
Aave Shield is a safeguard built into the Aave web interface. By default, it blocks swaps when the estimated price impact is above 25%. If a user still wants to continue, they must deliberately turn off the protection in Settings. So, the feature adds friction before a risky trade can go through. The Aave web app also shows Aave Shield as a global setting, which confirms that the feature exists at the interface level.
This incident did not come from a weakness in Aave’s lending contracts. Instead, it happened through a front-end swap flow that used CoW settlement. Because of that, a UI-level control was the most direct fix Aave could add quickly. It did not need to change the core protocol to do that.
Aave presents Shield as a way to stop accidental confirmations. At the same time, it still leaves room for advanced users. They can disable the safeguard if they knowingly want to accept high price impact.
Aave began talking about Shield soon after the incident. Public statements appeared immediately after the swap drew attention. By 19 March 2026, in the Asia/Kolkata time zone used for this report, the Aave web app already showed the Aave Shield toggle in global settings. That suggests the rollout was already active in the production interface.
Public materials do not fully specify the exact deployment timestamp for each code change. Still, the Aave interface is open source and is maintained in the aave/interface repository. So, that is the most likely place where UI changes such as Shield would be added.
Aave Shield reduces one specific kind of risk, but it does not solve every execution problem. First, it does not change how on-chain AMMs work. So, if a user disables Shield, or trades somewhere else, a large order can still destroy its own price in a shallow pool.
Second, the protection only applies inside Aave’s interface. It cannot protect users who swap through another front end or send custom transactions directly. Third, it depends on pre-trade estimates. Those estimates can change if routing changes, pool balances move, or solver behavior shifts. So, the final outcome can still differ from the estimate. Even so, in this incident, reports suggest the quote already looked catastrophic before execution.
Finally, Shield does not directly stop MEV. Even a private route can leak, and in this case, MEV extraction was visible in the same block. So, Shield is best understood as a practical warning system. It helps stop users before they sign an obviously dangerous trade, but it is not a full anti-MEV guarantee.
The Aave swap incident sits in a broader pattern: user-signed transactions and protocol operations can produce irreversible losses either through execution/market structure (illiquidity, MEV) or through bugs/misconfigurations.
Selected crypto incidents comparable to the Aave swap event
Large DeFi swaps do not work like exchanging cash at a bank. Instead, they trade against specific liquidity venues, often automated market makers. Because of that, the final price depends heavily on pool depth and routing.
So, users need to check price impact and minimum received very carefully. Slippage tolerance sets the minimum outcome a user is willing to accept. If that minimum is extremely low, the user is effectively allowing the system to complete a trade that makes little economic sense.
Users should also avoid placing very large swaps as a single market-style order. Instead, breaking the trade into smaller parts can help. A TWAP-style approach, for example, can reduce both price impact and MEV exposure. This is one of the clearest lessons from this case.
At the same time, users should treat MEV protection as a way to reduce risk, not eliminate it. Private routing can help, but it does not guarantee safety. As this incident suggests, leaks can still happen, and large visible transactions can still attract sophisticated MEV bots.
Finally, users should prefer venues with deep liquidity when trading large size. This incident shows why that matters. Even when a router is involved, the final route can still reach a pool that is far too shallow for the order. When that happens, price impact can become catastrophic very quickly.
Protocols and interfaces should not rely on a single warning or checkbox as the final defense for very large swaps. Public commentary around this incident makes that point clearly. A trade can be executed exactly as designed and still be disastrous for the user. So, technically correct execution is not enough when the user experience still leads someone into signing a ruinous order.
Protocols should also add hard sanity checks to routing systems. At a minimum, routers should reject paths that end in tiny liquidity pools when the trade size is too large relative to those reserves. This is the type of guardrail Aave Shield is trying to introduce through price impact limits.
In addition, intent-based systems need to handle solver and auction failure more safely. If a system can fall back from a reasonable route to a catastrophic one because of verification limits or solver failure, then it needs a safer abort mechanism. In other words, when the system cannot deliver a sensible route, it should fail safely instead of executing a terrible one.
Finally, protocols should assume MEV will appear around large and predictable flows. The same-block extraction and builder payment in this case show that clearly. Because of that, protocols should support private order flow, encrypted mempool options where possible, and routing that accounts for MEV risk from the start.
