5000万USDT换回3.5万美元AAVE：灾难如何发生？我们又该怪谁？

本文来自：@Ehsan1579

编译｜Odaily 星球日报（@OdailyChina）；译者｜ Ethan（@ethanzhang_web 3）

单看事件标题，大概率会误以为这是一起漏洞利用攻击。

事件核心是：有人将价值 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 前端界面：请求适配器报价时未附带钩子关联的应用数据，直接将错误结果传入签名流程，且仅依赖预警提示、无硬性拒绝机制，对于此类极端大额交易，这类风控措施完全不足以防范风险。

这是一次交易路由质量与风控护栏的极端性失败，直接将一笔合法合规的抵押品轮换操作，演变成了一场毁灭性的资产损失事件。