Virtual Currency - Alt Coin Discussion Thread

The $50 Million Route to Nowhere. WTF happened? And Who Should We Blame?

If you only saw the headline, you would assume exploit.

Someone “swapped $50.4 million of USDT for $35.9k of AAVE.”

When I first heard that, I was honestly stunned. So I went through the whole thing end to end: the transaction trace, the solver path, the contract calls, the historical reserves, the settlement data, the adapter flow, the Aave interface code, the CoW flashloan SDK, and the routing code that decides whether a quote is “reasonable.”

This was not a hack. Aave core did not fail. CoW settlement did not fail. Uniswap did not fail. Sushi did not fail. The transaction was valid, the signatures were valid, and the contracts all executed exactly as written. And yet nearly the entire economic value was destroyed, because the route it was allowed to take was absurd.

The chain did not fail. The route failed.

And I do not think it is honest to shrug this off as just “user error.” Yes, the user signed the order. But the software stack allowed a roughly $50 million collateral rotation to be quoted, signed, routed, and executed into a pool that only held about 331 AAVE. That should have been impossible, or at the very least hard-rejected long before settlement.

The transaction was 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f. It landed on Ethereum mainnet in block 24643151 on March 12, 2026, at transaction index 1. It used 3,780,570 gas and succeeded. The order owner was 0x98b9.... The transaction sender, and the solver that actually cleared the trade, was 0x3980..., identified in CoW competition data as tsolver.

The first thing to understand is that this was not a plain wallet-level USDT to AAVE swap. The sell token was aEthUSDT, Aave’s interest-bearing deposit token for USDT. The buy token was aEthAAVE, Aave’s interest-bearing deposit token for AAVE. So this was really an Aave collateral rotation that got routed through CoW Protocol’s settlement system and its flashloan adapter flow.

Before the trade, the wallet held about 50,432,693.075254 aEthUSDT and zero aEthAAVE. After the trade, it held only 4.980399 aEthUSDT and received 327.241335505966487788 aEthAAVE. So the wallet really did sell essentially the entire position.

The metadata makes it even clearer that the route was already poisoned before execution. The order came from the aave-v3-interface-collateral-swap flow. CoW’s API shows it as a signed sell order, while the app metadata marks it as a market-style collateral swap using smart slippage with 121 basis points. 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.

That is an incredibly important detail. The order was not “supposed” to return thousands or hundreds of thousands of AAVE and then somehow got destroyed in flight. It was already structured around an outcome in the low 300s of AAVE.

Once you follow the trace, the mechanics are brutally straightforward.

At the top level, the funds moved through CoW’s GPv2Settlement contract at 0x9008.... Before anything else, HooksTrampoline at 0x60bf... executed a permit on aEthUSDT, allowing the CoW vault relayer to pull the user’s funds without a separate approval transaction. Then GPv2VaultRelayer at 0xc92e... pulled 50,432,688.41618 aEthUSDT from the owner into settlement. So far, everything is standard.

Settlement then approved aEthUSDT to an unverified helper contract at 0xd524... and called it with selector 0x494b3137. That helper passed control to another unverified executor at 0x699c.... From there, the route becomes visible.

The first meaningful call was into Aave Pool 0x87870... using selector 0x69328dec, which is withdraw(address,uint256,address). That burned the aEthUSDT and withdrew the underlying USDT. Then the route hit the deep Uniswap V3 USDT/WETH pool at 0x4e68..., swapping the full 50,432,688.41618 USDT into 17,957.810805702142342238 WETH.

That leg was completely normal. It priced at about 2,808.4 USDT per WETH, which was fine for the time. No weirdness there. No thin liquidity. No bad math. The first hop was not the problem.

The problem was the second hop, and once you see the reserves, the rest of the story becomes inevitable.

After receiving 17,957.810805702142342238 WETH, the executor sent the entire amount into the SushiSwap V2 AAVE/WETH pool at 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

I checked that pool’s historical reserves at block 24643150, immediately before the bad trade. The pool held only:

331.631982538108027323 AAVE 17.653276196397688066 WETH

That is not a typo.

The route pushed nearly 17,958 WETH into a pool that only had 17.65 WETH on one side and only 331.63 AAVE total inventory on the other. The incoming WETH was about 1017x the pool’s WETH reserve.

This was not “a little too much slippage.” This was not “slightly thin liquidity.” This was a market-order path so extreme that it effectively asked a tiny constant-product pool to absorb a trade thousands of times too large.

The AMM did exactly what AMMs do. It gave up almost its entire AAVE side.

The Sushi pair emitted the critical Swap event. The executor put in 17,957.810805702142342238 WETH and got back only 331.305315608938235428 AAVE. After the swap, the pool was left with roughly:

0.326666929169791895 AAVE 17,975.464081898540030304 WETH

In plain English, about 99.9% of the pool’s AAVE inventory was drained in a single hop.

At the pre-trade reserves, the pool implied roughly $149.50 per AAVE. The user’s effective execution price was about 154,114.66 USDT per AAVE. That is more than 1000x worse than the pre-trade spot price.

That AAVE was then supplied back into Aave Pool with selector 0x617ba037, which is supply(address,uint256,address,uint16). The result was newly minted aEthAAVE sent back into settlement. Settlement ultimately transferred 327.241335505966487788 aEthAAVE to the user. About 4.06398010297174764 aEthAAVE remained on the settlement contract as surplus relative to the user payout.

So settlement did not suddenly distort a good execution into a bad one. It finalized what the route had already produced.

That is the key point, and it is worth saying plainly: the catastrophic outcome was already baked into the route before execution.

The helper calldata embedded in the route targeted roughly 331.272185078031026739 on the buy side. The signed minimum was 324.949260918413591035. The actual payout was 327.241335505966487788. All of the meaningful numbers were already in the low 300s of AAVE before the order was ever settled.

The route was born bad.

Where's the bug?

Each layer checks the wrong thing.

Each layer checks that the trade is executable, signed, and nonzero. Almost none of the critical layers check whether the route is economically sane.

The first real code smell is in the Aave interface’s CoW adapter quote path. The function that is supposed to include adapter-specific appData when requesting a quote is simply disabled.

That means the Aave interface asks CoW for a quote without the flashloan and hook metadata that will actually be attached when the order is posted. In other words, the thing being quoted is not fully the thing being executed. The code comments even say the purpose of this helper was to make adapter quotes more precise, and then the function is hard-disabled.

The second, and more serious, issue is in CoW’s quote competition logic. In the public services code, a quote is treated as “reasonable” if it has positive gas and a nonzero output amount.

That is an astonishingly weak definition of reasonableness for a system routing eight-figure orders.

There is no oracle sanity check there. No “this is 500x worse than spot” check. No “this route empties the pool” check. No “final-hop liquidity is microscopic relative to notional size” check. If a solver returns a route that is executable and nonzero, it can still be accepted.

That is the core bug.

The third issue is how Uniswap-v2-style liquidity is modeled. The code uses standard constant-product math and only rejects arithmetic impossibilities like zero reserves, underflow, or reserve overflow.

That code does not ask whether the pool is big enough for the route. It only asks whether the swap is mathematically valid. So a pool with 331 AAVE is still considered a valid venue for a 17,957 WETH buy, because constant-product math can produce a nonzero result. It will just be a catastrophically bad result.

Then the flashloan SDK takes that bad quote and bakes it directly into the order and hook payload.

That is why I keep saying the route was born bad. The adapter layer does not “discover” a fresh bad amount at execution time. It serializes the quoted bad amount into the hook data and deterministic instance address. Once the bad quote exists, the rest of the machinery faithfully carries it forward

Even CoW’s order-validation logic does not really save the user here, because it only checks whether the order is outside the quoted market price, not whether the quote itself is insane relative to real liquidity.

That is a consistency check. If the quote itself is already nonsense, the order can still pass.

And then there is the UI side. The Aave interface does have a high-price- impact warning, but it is not a hard kill switch. It becomes a confirmation checkbox above 20% loss.

And once the user checks the box, the block is cleared.

So even a trade that destroys almost all value is treated as something the user can still proceed with after acknowledging it, not something the system must hard-refuse.

That is why I do not buy the lazy explanation that this was simply “the user doing something dumb.” The user did sign it. But the stack had multiple opportunities to make this impossible, and instead every layer said some version of: nonzero, executable, signed, proceed.

The route was not mangled later

This part matters because it eliminates a lot of bad theories. The public Aave interface flow behind aave-v3-interface-collateral-swap computes a slippage-adjusted buy amount from the quote, network fee, partner fee, and flashloan fee in useSwapOrderAmounts.ts:139, converts it to buyAmountBigInt in useSwapOrderAmounts.ts:331, and then signs exactly that amount in CollateralSwapActionsViaCoWAdapters.tsx:191. The adapter contracts then verify that the signed order’s fields match the stored values exactly in AaveV3BaseAdapter.sol:141. CoW settlement then enforces the signed limit relation in GPv2Settlement.sol:337. So the onchain result was not worse than what the signed order allowed. The user got more than the minimum they signed for. That proves the catastrophe happened before settlement, not inside settlement.

Where the missing value went

The next transaction in the same block, 0x45388b0f..., backran the now-broken Sushi AAVE/WETH pool. Once the bad route had stuffed the pool with WETH and stripped out nearly all the AAVE, the backrunner sold AAVE back into the pool and extracted the imbalance.

The backrun pulled out roughly 17,929.770158685933 WETH. It then paid about 13,087.73 ETH to the block builder and another 4,824.31 ETH to the sender.

That is where the economic loss ended up. It turned almost instantly into same-block MEV and builder revenue.

Nobody manipulated the Sushi pool before the trade to trap the user. I checked the block-level chronology. The AAVE/WETH Sushi pair is first touched by this transaction at tx index 1. The very next transaction, tx index 2, is the first backrun against the distortion this trade created. Tx index 3 also touches the pair as the market continues normalizing. So the chronology is clean: this transaction created the toxic price, and the next one harvested it.

So whose fault was it?

If you are asking whether Aave V3 core broke, the answer is no. Aave Pool did exactly what it was told to do: it withdrew USDT and supplied AAVE.

If you are asking whether CoW’s GPv2Settlement contract broke, the answer is no. Settlement enforced a valid signed order and paid more than the signed minimum.

If you are asking whether Uniswap V3 or SushiSwap’s pair contract broke, the answer is also no. They both priced the swaps according to their own rules.

The real failure sits higher up.

The primary failure is on the CoW routing, quote, and solver side. The stack allowed a gigantic order to terminate in a microscopic final-hop pool because its definition of a “reasonable” route was far too weak. In practice, the system was willing to accept a route as long as it was executable and nonzero, even if it was economically insane.

The Aave interface carries secondary responsibility. It requested adapter quotes without hook-aware appData, passed the resulting amounts straight into the signed order flow, and relied on warnings rather than hard rejections. For a trade this extreme, that is not enough.

This was a route-quality and guardrail failure so extreme that it turned a legitimate transaction into a financial massacre.