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、消費したガス量は 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 を得ることを期待していたわけではなく、途中で何らかの理由で破壊されたのです。構築の初めから、300 以上の 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 枚であり、すべてのコア数値は決済前に 300 枚以上の AAVE の量にロックされています。

このルーティングは最初から悪かったのです。

脆弱性はどこにあるのか？

答えは：システムの各層の検証メカニズムが、誤った次元を確認していることです。

すべてのレベルは取引が実行可能か、署名が有効か、金額がゼロでないかを確認するだけで、経済的な観点から取引ルーティングが合理的かどうかをほとんど確認していない。これはメカニズムの失守の核心的な根源です。

Aave インターフェースアダプタの見積もりパスのコード欠陥

最初の明らかなコードの異常点は、Aave インターフェースの CoW アダプタの見積もりプロセスに現れます：本来、見積もりをリクエストする際にアダプタ専用のアプリケーションデータを付加するための関数が、直接強制的に無効化されています。

出典：rates.helpers.ts:93と adapters.helpers.ts:194

これは、Aave インターフェースが CoW に見積もりをリクエストする際に、実際に発行される注文時に付加されるフラッシュローンやフックのメタデータを添付していないことを意味します。言い換えれば、見積もりされたものは実行されるべきものとは完全に一致していません。コードのコメントには、このヘルパー関数の目的はアダプタの見積もりをより正確にするためであると記載されていますが、この関数は強制的に無効化されています。

CoW 見積もり競争ロジックの合理性判定があまりにも薄弱（核心的な脆弱性）

第二の、そして最も深刻な問題は、CoW プロトコルの見積もり競争ロジックにあります：その公共サービスコードでは、見積もりのガス費用が正で、出力金額がゼロでない限り、「合理的な見積もり」と見なされます。

出典：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 フロントエンドインターフェースです：アダプタの見積もりをリクエストする際にフック関連のアプリケーションデータを添付せず、誤った結果を署名プロセスに直接渡し、警告提示にのみ依存し、ハードな拒否メカニズムがなく、こうした極端な大額取引に対してはリスクを防ぐには不十分です。

これは取引ルーティングの質とリスク管理の極端な失敗であり、合法的かつ適切な担保ローテーション操作を、壊滅的な資産損失事件に変えてしまいました。