5000 萬 USDT 換回 3.5 萬美元 AAVE：災難如何發生？ 我們又該怪誰？

本文来自：@Ehsan1579

編譯：Ethan，

單看事件標題，大機率會誤以為這是一起漏洞利用攻擊。

事件核心是：

我初次听闻此事时，着实震惊。 因此，我徹頭徹尾地梳理了整個事件：交易追蹤、求解器路徑、合約調用、歷史儲備、結算資料、適配器流程、Aave 介面代碼、CoW 閃電貸 SDK，以及判斷報價是否「合理」的路由代碼。

​ Aave 核心协议没有出错。 CoW 结算没有出错。 Uniswap 沒有出錯。 SushiSwap 没有出错。 交易是有效的，簽名是有效的，所有合約都嚴格按照代碼執行。 然而，幾乎全部的經濟價值都被摧毀了，只因為它被允許走上的路由荒謬至極。

在我看來，輕描淡寫將此事歸為單純的“用戶操作失誤”，並非客觀嚴謹的態度。 誠然，用戶完成了訂單簽名，但整套軟體系統，竟允許一筆涉及近 5000 萬美元抵押品輪換的操作，完成報價、簽名、路由規劃直至最終執行，且全部流程指向一個僅持有約 331 枚 AAVE 的低流動性池。 這本該是完全不可能發生的事，至少理應在結算環節啟動前，就被系統強硬攔截拒絕。

交易核心資訊溯源

本次異常交易雜湊為：0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f，於 2026 年 3 月 12 日在以太坊主區塊高度 3780570 单位，交易执行成功。 訂單歸屬錢包位址為 0x98b9 開頭，實際執行交易的求解器（交易發送方）位址為 0x3980 開頭，在 CoW 競賽資料中標記為 tsolver。

首先要明白，這不是一次簡單的錢包層面的 USDT 到 AAVE 兌換。 賣出代幣是 aEthUSDT，即 Aave 平台上生息的 USDT 存款憑證。 買入代幣是 aEthAAVE，即 Aave 平台上生息的 AAVE 存款憑證。 所以，這實際上是一次透過 CoW 協議的結算系統及其閃電貸適配器流程進行的 Aave 抵押品輪換。

交易前，該錢包持有約 50,432,693.075254 個 aEthUSDT 和 0 個 aEthAAVE。 交易後，它只剩 4.980399 個 aEthUSDT，並收到了 327.241335505966487788 個 aEthAAVE。 實際上，該錢包賣出了幾乎全部部位。

元資料更清楚地表明，路由在執行前就已經是「有毒」的。 訂單來自 aave-v3-interface-collat​​eral-swap 流程。 CoW 的 API 將其顯示為已簽署的賣出訂單，而應用元資料則將其標記為使用 121 個基點智慧滑點的市價式抵押品互換。 簽名的賣出金額是 50,432,688.41618 個 aEthUSDT。 簽名的最低買入金額是 324.949260918413591035 個 aEthAAVE。 實際結算支付了 327.241335505966487788 個 aEthAAVE。

这是一个极其重要的细节。 這筆訂單本來就沒期望獲得成千上萬的 AAVE，然後在中途不知何故被摧毀。 它在建構之初，就圍繞著三百多個 AAVE 這樣的結果。

路由崩盤的完整連結

一旦你跟著交易追踪，整個過程便殘酷地直截了當。

頂層資金流轉核心依托 CoW 協議 0x9008 開頭的 GPv2Settlement 結算合約。 首先，0x60bf 開頭的 HooksTrampoline 合約完成 aEthUSDT 授權操作，允許 CoW 金庫中繼器無需單獨交易授權，即可提取用戶資產；隨後，0xc92e 開頭的 GPv2VaultRelayer 合約從用戶錢包提取 50432688.41618 計算 M

结算合约随后将 aEthUSDT 操作权限授予 0xd524 开头的未开源辅助合约，并通过函数选择器 0x494b3137 发起调用；该辅助合约再将执行权限转交至 0x699c 开头的未开源执行器合约，至此，异常交易路由的全貌彻底暴露。

首個有效呼叫指向 0x87870 開頭的 Aave 資金池合約，透過 withdraw 函數（選擇器 0x69328dec）銷毀 aEthUSDT，贖回底層原生 USDT；隨後路由跳轉至 0x4e68 開頭的 Uniswap V3 深度 US 兑换为 17957.810805702142342238 枚 WETH。

此階段的交易完全正常：兌換匯率約為 2808.4 USDT 兌換 1 枚 WETH，符合當時市場行情，無流動性不足問題，無計算偏差，第一跳交易鏈路不存在任何異常。

問題出在第二跳，一旦你看到流動性儲備，剩下的故事就不可避免了。

執行器取得 17957.810805702142342238 枚 WETH 後，將全部資金轉入 0xd75ea151a61d06868e31f8988d28dfe5e9df57b

我檢視了該交易池在異常交易發生前一刻（區塊高度 24643150）的歷史流動性儲備數據，池內僅持有：

331.631982538108027323 枚 AAVE、17.653276196397688066 枚 WETH

這並非資料輸入錯誤，而是鐵一般的事實。

這條交易路由，將近 17958 枚 WETH 全部注入一個僅儲備 17.65 枚 WETH、對應 AAVE 總庫存僅 331.63 枚的微型交易池，輸入的 WETH 體積竟是池內 WETH 儲備的約 1017 倍。

這絕非「滑點偏高」或「流動性略薄」的常規問題，而是一條極端荒謬的市價單執行路徑，相當於強迫一個體量極小的恆定乘積 AMM 池，承接一筆規模超出自身數千倍的巨額交易。

AMM 交易池依照既定演算法執行了操作，近乎耗盡了池內全部 AAVE 儲備。

SushiSwap 交易對觸發核心 Swap 交換事件：執行器轉入 17957.810805702142342238 枚 WETH，僅換回 331.305315608938235428 枚 AAVE。 交易完成後，此池剩餘流動性約為：

0.326666929169791895 枚 AAVE、17975.464081898540030304 枚 WETH

說穿了，池中約 99.9% 的 AAVE 庫存在一跳中被抽乾。

根據交易前的儲備，池子隱含的 AAVE 價格約為 149.50 美元。 用戶的實際執行價格約為 154,114.66 USDT 兌 1 AAVE。 這比交易前的現貨價格差了超過 1000 倍。

接著，這些 AAVE 被供應回 Aave 資金池，使用選擇器 0x617ba037，即 supply(address,uint256,address,uint16)。 結果是新鑄造的 aEthAAVE 被送回結算合約。 結算合約最終將 327.241335505966487788 個 aEthAAVE 轉給了使用者。 大約 4.06398010297174764 個 aEthAAVE 作為相對於用戶支付的盈餘，留在了結算合約中。

所以，結算並沒有突然將一個好的執行結果扭曲成一個壞結果。 它只是最終敲定了路由早已產生的結果。

這是關鍵點，值得明確說出： 災難性的結果在路由執行前就已經「預設」在其中了。

路由內嵌的輔助合約調用資料中，買入端目標金額約為 331.272185078031026739 枚，用戶簽名約定的最低買入金額為 324.949260918413591035 枚，實際結算金額為 327.2413852541646 枚，所有核心數值在結算前，就鎖定在三百餘枚 AAVE 的量級。

漏洞在哪裡？

答案是：系統每一層校驗機制，都在核查錯誤的維度。

所有層級僅校驗交易是否可執行、簽名是否有效、金額是否非零，

首個明顯的程式碼異常點，出現在 Aave 介面的 CoW 適配器報價流程中：原本用於在請求報價時，附帶適配器專屬應用資料的函數，被直接強制停用。

來源：rates.helpers.ts:93和 adapters.helpers.ts:194

這意味著 Aave 介面在向 CoW 請求報價時，。 換句話說，被報價的東西並不完全是要被執行的東西。 程式碼註解甚至說這個助手函數的目的是為了讓適配器報價更精確，然後這個函數卻被硬性停用了。

第二個也是最嚴重的問題，在於 CoW 協議的報價競爭邏輯：其公共服務代碼中，，就會被判定為「合理報價」。

來源：quote.rs:31

對於一個處理八位數訂單的路由系統來說，的「合理性」定義。

系統未接入預言機做價格健全性校驗，無「報價偏離現貨價格 500 倍以上」的攔截機制，無「路由會徹底抽乾流動性池」的風險判定，無「最後一跳流動性與訂單規模嚴重不匹配」的預警；只要求解器返回可執行、非零的路由方案，就會被系統接納，

第三個問題，在於 Uniswap V2 風格的流動性池建模方式：程式碼僅採用標準恆定乘積演算法，僅拒絕零儲備、數值下溢、儲備溢出等數學層面的不可能情況，不做經濟層面的可行性校驗。

來源：pool_fetching.rs:118和 pool_fetching.rs:153

此段程式碼不會判斷流動性池體量是否足以承接對應路由交易，僅判斷交換操作在數學上是否有效。 因此，即便一個僅儲備 331 枚 AAVE 的微型池，也會被判定為承接 17957 枚 WETH 買入請求的有效場所，只因恆定乘積演算法能算出非零結果，卻完全無視這個結果會帶來毀滅性的資產損耗。

隨後，閃電貸 SDK 直接將這份失效報價，固化到訂單與鉤子的執行負荷中，沒有做任何二次風險攔截。

接著：

來源：index.js:484和 index.js:591

這就是為什麼我一直說這條路由是「生來就壞」。 適配器層在執行時「發現」一個新的壞金額。 它。 一旦糟糕的報價存在，其餘機制就會忠實地將其傳遞下去。

即使是 CoW 的訂單驗證邏輯在這裡也，因為它只檢查訂單是否超出報價時的市場價格，而不檢查報價本身相對於實際流動性是否荒謬。

來源：order_validation.rs:694

這是一致性檢查。

Aave 介面確實有高價格衝擊警告，但它。 當價值損失超過 20%時，它變成一個確認複選框。

一旦使用者勾選了複選框，障礙就被清除了：

來源：helpers.ts:24和 HighPriceImpactWarning.tsx:35

因此，即便這筆交易會近乎清空全部資產價值，系統也僅將其判定為需用戶確認的操作，而非系統必須強硬拒絕的高危險交易，預警機製完全失去了風險攔截作用。

基於以上所有機制失守，我絕不認同「這只是用戶傻」的敷衍結論。 用戶確實完成了簽名，但整套軟體系統有無數次機會攔截這場災難，卻每一層都僅做了基礎校驗，判定「非零、可執行、已簽名」後直接放行，最終釀成惡果。

路由未被竄改

這一環節至關重要，直接排除了大量錯誤猜測：aave-v3-interface-collateral-swap 對應的 Aave 官方界面流程，會在 useSwapOrderAmounts.ts 文件第 139 行，結合報價、網絡費用、合作方費用、閃電貸費用，計算滑點調整後的買入金額；第 331 網絡費用隨後將其轉換為 BigAmount 數字 CollateralSwapActionsViaCoWAdapters.tsx 檔案第 191 行，對該金額完成精準簽名。

後續轉接器合約在 AaveV3BaseAdapter.sol 檔案第 141 行，校驗簽章訂單欄位與儲存數值完全相符；CoW 結算合約在 GPv2Settlement.sol 檔案第 337 行，強制執行簽章約定的限額規則。 因此，鏈上執行結果並未超出簽名訂單允許的範圍，使用者實際收到的資產，甚至高於簽名約定的最低限額。

這足以證明：災難發生在結算環節之前，而非結算過程中，路由的致命缺陷早已註定結局。

消失的價值去了哪裡？

同一區塊內的下一筆交易（哈希 0x45388b0f 開頭），針對被破壞的 SushiSwap AAVE/WETH 池完成了回跑套利。 異常交易用鉅量 WETH 塞滿池子、抽乾絕大部分 AAVE 後，套利者立即將 AAVE 賣回池中，收割流動性失衡帶來的超額價值。

本次回跑套利共提取約 17929.770158685933 枚 WETH，隨後向該區塊構建者支付約 13087.73 枚 ETH，向套利執行地址支付約 4824.31 枚 ETH。

用戶損失的全部經濟價值，最終幾乎瞬間轉化為同一區塊內的 MEV 套利收益與區塊建構者收益。

另外核查區塊級時間序可以確認：交易前無人惡意操縱 SushiSwap 交易池設套誘騙用戶，該 AAVE/WETH 交易對首次被觸及，就是本次異常交易（交易索引 1）；緊接著的下一筆交易（交易索引 2），就針對本次交易回跑 時間軸清晰印證：本次異常交易製造了極端扭曲價格，後續交易直接收割了這份扭曲收益。

那麼，是誰的錯？

如果你問 Aave V3 核心協定是否崩潰了，答案是。 Aave 資金池完全依照指示執行操作，正常完成 USDT 贖回與 AAVE 存入流程。

如果你問 CoW 的 GPv2Settlement 合約是否崩潰了，答案是。 結算強制執行了一份有效的簽名訂單，並支付了高於簽名最低限度的金額。

如果你問 Uniswap V3 或 SushiSwap 的交易對合約是否崩潰了，答案同樣是。 兩類交易池均依照自身演算法規則完成交易定價。

真正的系統性失敗，發生在更上層的路由與風控層面：

：整套系統對「合理路由」的判定標準過於薄弱，允許千萬美元級巨額訂單，最終流向微型低流動性池，只要路由可執行、非零就予以接納，完全無視經濟層面的極端不合理性。

：請求適配器報價時未附帶鉤子關聯的應用數據，直接將錯誤結果傳入簽名流程，且僅依賴預警提示、無硬性拒絕機制，對於此類極端大額交易，這類風控措施完全不足以防範風險。

這是一次交易路由品質與風控護欄的極端性失敗，直接將一筆合法合規的抵押品輪換操作，演變成了一場毀滅性的資產損失事件。