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

本文來自：@Ehsan1579

編譯：Ethan，Odaily 星球日報

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

事件核心是：有人將價值 5040 萬美元的 USDT，最終僅兌換到價值 3.59 萬美元的 AAVE。

我初次聽聞此事時，著實震驚。因此，我徹頭徹尾地梳理了整個事件：交易追蹤、求解器路徑、合約調用、歷史儲備、結算數據、適配器流程、Aave 界面代碼、CoW 閃電貸 SDK，以及判斷報價是否"合理"的路由代碼。

**這不是一次黑客攻擊。**​ Aave 核心協議沒有出錯。CoW 結算沒有出錯。Uniswap 沒有出錯。SushiSwap 沒有出錯。交易是有效的，簽名是有效的，所有合約都嚴格按照代碼執行。然而，幾乎全部的經濟價值都被摧毀了，只因為它被允許走上的路由荒謬至極。

公鏈沒有出問題，出問題的是路由。

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

交易核心信息溯源

本次異常交易哈希為：0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f，於 2026 年 3 月 12 日在以太坊主網區塊高度 24643151 處確認，交易索引為 1，消耗 Gas 量 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-collateral-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 枚 aEthUSDT 進入結算流程，截至此環節，所有操作均符合正常邏輯。

結算合約隨後將 aEthUSDT 操作權限授予 0xd524 開頭的未開源輔助合約，並通過函數選擇器 0x494b3137 發起調用；該輔助合約再將執行權限轉交至 0x699c 開頭的未開源執行器合約，至此，異常交易路由的全貌徹底暴露。

首個有效調用指向 0x87870 開頭的 Aave 資金池合約，通過 withdraw 函數（選擇器 0x69328dec）銷毀 aEthUSDT，贖回底層原生 USDT；隨後路由跳轉至 0x4e68 開頭的 Uniswap V3 深度 USDT/WETH 交易池，將全部 50432688.41618 枚 USDT 兌換為 17957.810805702142342238 枚 WETH。

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

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

執行器獲取 17957.810805702142342238 枚 WETH 後，將全部資金轉入 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4 地址的 SushiSwap V2 AAVE/WETH 交易池。

我核查了該交易池在異常交易發生前一刻（區塊高度 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.241335505966487788 枚，所有核心數值在結算前，就鎖定在三百餘枚 AAVE 的量級。

這條路由生來就是壞的。

漏洞在哪兒？

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

所有層級僅校驗交易是否可執行、簽名是否有效、金額是否非零，卻幾乎沒有核心層級校驗交易路由在經濟層面是否具備合理性，這是機制失守的核心根源。

Aave 界面適配器報價路徑的代碼缺陷

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

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

這意味著 Aave 界面在向 CoW 請求報價時，並沒有附上實際發布訂單時會附加的閃電貸和鉤子元數據。換句話說，被報價的東西並不完全是要被執行的東西。代碼註釋甚至說這個助手函數的目的是為了讓適配器報價更精確，然後這個函數卻被硬性禁用了。

CoW 報價競爭邏輯的合理性判定過於薄弱（核心漏洞）

第二個也是最嚴重的問題，在於 CoW 協議的報價競爭邏輯：其公共服務代碼中，只要報價 Gas 費用為正、輸出金額非零，就會被判定為"合理報價"。

來源：quote.rs:31

對於一個處理八位數訂單的路由系統來說，這是一個令人震驚的薄弱的"合理性"定義。

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

Uniswap V2 類流動性建模邏輯的缺陷

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

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

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

閃電貸 SDK 與訂單驗證機制的二次失守

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

接著：

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

這就是為什麼我一直說這條路由是"生來就壞"。適配器層並沒有 在執行時"發現"一個新的壞金額。它將已報價的壞金額序列化到了鉤子數據和確定的實例地址中。一旦糟糕的報價存在，其餘機制就會忠實地將其傳遞下去。

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

來源：order_validation.rs:694

這是一致性檢查。如果報價本身就已經是胡言亂語，訂單仍然可以通過。

UI 前端預警機制形同虛設

Aave 界面確實有高價格衝擊警告，但它不是一個硬性的熔斷開關。當價值損失超過 20%時，它變成一個確認複選框。

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

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

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

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

路由未被篡改

這一環節至關重要，直接排除了大量錯誤猜測：aave-v3-interface-collateral-swap 對應的 Aave 官方界面流程，會在 useSwapOrderAmounts.ts 文件第 139 行，結合報價、網絡費用、合作方費用、閃電貸費用，計算滑點調整後的買入金額；第 331 行將其轉換為 buyAmountBigInt 數值；隨後在 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），就针对本次交易造成的价格扭曲完成首次回跑；交易索引 3 也在市场修复过程中触及该交易对。时间线清晰印证：本次异常交易制造了极端扭曲价格，后续交易直接收割了这份扭曲收益。

那麼，是誰的錯？

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

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

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

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

主要責任方為 CoW 協議的路由、報價與求解器模塊：整套系統對"合理路由"的判定標準過於薄弱，允許千萬美元級巨額訂單，最終流向微型低流動性池，只要路由可執行、非零就予以接納，完全無視經濟層面的極端不合理性。

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

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