2024年3月、Aaveは従来のDeFi災害の物語を覆す前例のない清算事件を経験した。市場の暴落や外部攻撃、コアシステムの破壊なしに、わずか数時間で約2700万ドル相当のユーザーポジションが強制清算された。この出来事はコミュニティに衝撃を与えたが、特に注目すべきはその原因だった。悪意のある攻撃者ではなく、むしろこの種のシナリオを防ぐために設計された保護メカニズムが引き起こしたものであった。合計34のユーザーアカウントが約10,938 wstETHを保有していたが、その担保はオンチェーンのボットによって清算され、プロトコル自体に悪い債務は一切発生しなかった。これはAaveの堅牢なアーキテクチャの証左である。リスク管理企業のChaos Labsは、CEOのOmer Goldbergを通じて最初に公式声明を出し、「悪い債務は発生せず、影響を受けたすべてのユーザーには完全に補償される」と安心感を与えた。Aave Labsの創設者Stani Kulechovもソーシャルメディア上でこの立場を強調し、プロトコルのコアシステムは破損していないと明言した。しかし、その背後には複雑な技術的物語が潜んでおり、DeFiシステムの清算管理における意外な脆弱性を明らかにした。## セーフガードが清算の引き金に変わるとき根本原因は、CAPO（Capped Asset Price Oracle）と呼ばれる特殊なオラクルメカニズムにあった。これは価格操作を防ぐために設計されたもので、wstETHのようなステーキング報酬を継続的に蓄積する資産の価格を不正に操作されるのを防ぐためのものだ。Aaveは、悪意のある者が交換レートを人工的に引き上げるシナリオに対抗するためにCAPOを導入した。この仕組みは、二つの同期したパラメータに依存している。ひとつはsnapshotRatio（交換レートのスナップショット、3日ごとに最大3％の増加に制限）、もうひとつはsnapshotTimestamp（そのスナップショットのタイムスタンプで、制限なし）。これらは常に同期して更新されるべきだが、何らかの理由で同期が崩れると、計算される最大許容交換レートが実際の市場価格から大きく乖離してしまう。実際に起きたのはこれだ。システムは、snapshotRatioを約1.1572から目標の1.2282へ引き上げようとしたが、オンチェーンの制約により1.1919までしか増加できなかった。同時に、snapshotTimestampは7日前の基準点から直接跳ね上がり、制限なく更新された。この非同期の更新により、CAPOはwstETHの最大許容交換レートを約1.1939と計算し、これは実際の市場価格より約2.85％低い値となった。通常の取引環境では、この乖離は微小なノイズとみなされるかもしれない。しかし、AaveのE-Mode（効率モード）はこの計算を根本的に変える。E-Modeは、ユーザーが通常の借入よりもはるかに高いレバレッジ比率を利用できる仕組みであり、価格の乖離に対して非常に敏感なポジションを生み出す。プロトコルがwstETHの価値を過小評価したことで、以前は安全だったポジションが一気に清算閾値を超え、オンチェーンの清算ボットが自動的に契約を実行した。利益の流れとしては、清算者は約116 ETHの報酬を獲得し、アービトラージャーはAaveの過小評価されたオラクル価格と実市場価格の差を突いて約382 ETHを稼ぎ出した。合計で約499 ETH（当時の価値で約127万ドル）が影響を受けたユーザーポジションから移動し、現在のETH価格約2,110ドルを考慮すると、これらの数字はより現実的な規模となる。## 清算対応と補償：Chaos Labsのコミットメントこの事件は、リスク管理を担うChaos Labsにとって複雑な局面をもたらした。オラクル設定の一部責任を負う立場として、迅速にダメージコントロールに動いた。Omer Goldbergは、「影響を受けたすべてのユーザーに完全な補償を行う」と公に約束しつつ、「プロトコルのインフラレベルでのオラクル設定ミスは深刻な教訓だ」と認めた。補償のための対応は段階的に進められた。まず、影響を受けたwstETH（CoreとPrime）の借入上限を1に引き下げ、AaveのRisk Stewardメカニズムを通じて二つのパラメータを手動で調整した。その後、パラメータの修正が完了すると、借入上限は元の値（Core：180,000、Prime：70,000）に戻された。補償の実行にあたっては、Chaos LabsはBuilderNetを通じて約141.5 ETHを回収し、Aave DAOのトレジャリーからの補助も得た。総補償額は約345 ETH（過去の価格を基に約87万ドル相当）に達し、すべての影響を受けたアカウントに完全に行き渡るよう設計された。このコミットメントは、技術的な失敗にもかかわらず、ユーザートラストを維持しようとするエコシステムの決意を示すものだった。## オラクル失敗から学ぶ：DeFiの清算履歴におけるパターンこの事件は孤立して起きたわけではない。DeFiエコシステムは、過去にもオラクルに関わる災害に何度も直面し、連鎖的な清算やシステム全体の損害を引き起こしてきた。2024年2月のMoonwellのオラクル誤設定では、cbETHの価格が一時的に約1ドル（市場価値は約2200ドル）と誤表示され、多額の清算と約180万ドルのプロトコルの悪債を生んだ。以前の事例には、Mango Marketsの操作攻撃やEuler Financeの脆弱性もあり、いずれも数億ドル規模の損失をもたらしている。しかし、Aaveのケースは特に特徴的だ。従来のオラクル災害は、外部データの改ざんや価格フィードの操作に起因していたのに対し、今回は内部のセキュリティアーキテクチャに由来している点だ。特に、誤ったパラメータ設定が、もともと操作を防ぐために設計された保護層を逆に破壊的な道具に変えてしまったのである。## 「コードは法なり」のパラドックス：不完全なシステムにおける教訓DeFiの根底にある哲学は、「コードは法なり」—スマートコントラクトは人間の介入なしに自律的に実行され、透明性と信頼性を確保するというものだ。しかし、この原則には潜在的な脆弱性も含まれる。パラメータの誤設定や技術的ミスによって、悪意なくしてもコードは同じく冷徹に動作する。停止ボタンも人間の上書きも存在しないため、影響を受けたユーザーは警告もなく清算されてしまう。Chaos Labsの補償約束は、即時の経済的損失を埋めるものだが、根本的なエンジニアリングの問題を解決するものではない。真のシステム強化には、パラメータ更新の厳格な検証、オンチェーン制約のリアルタイム整合性チェック、そして誤動作を未然に察知し管理者に警告を送る早期警戒システムの導入が必要だ。今回のAave清算事件は、迅速な対応と完全補償によって一時的に収束したものの、DeFi全体にとって重要な脆弱性を浮き彫りにした。今後、より高度な清算メカニズムや複雑な担保構造が進むにつれ、保護メカニズム自体が清算の媒介となるリスクも高まる。業界は、これらの誤りを防ぐだけでなく、主要システムの故障時にも正しく機能するフェイルセーフを設計することに取り組む必要がある。
Aaveの清算セーフガードが裏目に出た時：$27 万オラクル障害の内幕
2024年3月、Aaveは従来のDeFi災害の物語を覆す前例のない清算事件を経験した。市場の暴落や外部攻撃、コアシステムの破壊なしに、わずか数時間で約2700万ドル相当のユーザーポジションが強制清算された。この出来事はコミュニティに衝撃を与えたが、特に注目すべきはその原因だった。悪意のある攻撃者ではなく、むしろこの種のシナリオを防ぐために設計された保護メカニズムが引き起こしたものであった。合計34のユーザーアカウントが約10,938 wstETHを保有していたが、その担保はオンチェーンのボットによって清算され、プロトコル自体に悪い債務は一切発生しなかった。これはAaveの堅牢なアーキテクチャの証左である。
リスク管理企業のChaos Labsは、CEOのOmer Goldbergを通じて最初に公式声明を出し、「悪い債務は発生せず、影響を受けたすべてのユーザーには完全に補償される」と安心感を与えた。Aave Labsの創設者Stani Kulechovもソーシャルメディア上でこの立場を強調し、プロトコルのコアシステムは破損していないと明言した。しかし、その背後には複雑な技術的物語が潜んでおり、DeFiシステムの清算管理における意外な脆弱性を明らかにした。
セーフガードが清算の引き金に変わるとき
根本原因は、CAPO（Capped Asset Price Oracle）と呼ばれる特殊なオラクルメカニズムにあった。これは価格操作を防ぐために設計されたもので、wstETHのようなステーキング報酬を継続的に蓄積する資産の価格を不正に操作されるのを防ぐためのものだ。Aaveは、悪意のある者が交換レートを人工的に引き上げるシナリオに対抗するためにCAPOを導入した。
この仕組みは、二つの同期したパラメータに依存している。ひとつはsnapshotRatio（交換レートのスナップショット、3日ごとに最大3％の増加に制限）、もうひとつはsnapshotTimestamp（そのスナップショットのタイムスタンプで、制限なし）。これらは常に同期して更新されるべきだが、何らかの理由で同期が崩れると、計算される最大許容交換レートが実際の市場価格から大きく乖離してしまう。
実際に起きたのはこれだ。システムは、snapshotRatioを約1.1572から目標の1.2282へ引き上げようとしたが、オンチェーンの制約により1.1919までしか増加できなかった。同時に、snapshotTimestampは7日前の基準点から直接跳ね上がり、制限なく更新された。この非同期の更新により、CAPOはwstETHの最大許容交換レートを約1.1939と計算し、これは実際の市場価格より約2.85％低い値となった。
通常の取引環境では、この乖離は微小なノイズとみなされるかもしれない。しかし、AaveのE-Mode（効率モード）はこの計算を根本的に変える。E-Modeは、ユーザーが通常の借入よりもはるかに高いレバレッジ比率を利用できる仕組みであり、価格の乖離に対して非常に敏感なポジションを生み出す。プロトコルがwstETHの価値を過小評価したことで、以前は安全だったポジションが一気に清算閾値を超え、オンチェーンの清算ボットが自動的に契約を実行した。
利益の流れとしては、清算者は約116 ETHの報酬を獲得し、アービトラージャーはAaveの過小評価されたオラクル価格と実市場価格の差を突いて約382 ETHを稼ぎ出した。合計で約499 ETH（当時の価値で約127万ドル）が影響を受けたユーザーポジションから移動し、現在のETH価格約2,110ドルを考慮すると、これらの数字はより現実的な規模となる。
清算対応と補償：Chaos Labsのコミットメント
この事件は、リスク管理を担うChaos Labsにとって複雑な局面をもたらした。オラクル設定の一部責任を負う立場として、迅速にダメージコントロールに動いた。Omer Goldbergは、「影響を受けたすべてのユーザーに完全な補償を行う」と公に約束しつつ、「プロトコルのインフラレベルでのオラクル設定ミスは深刻な教訓だ」と認めた。
補償のための対応は段階的に進められた。まず、影響を受けたwstETH（CoreとPrime）の借入上限を1に引き下げ、AaveのRisk Stewardメカニズムを通じて二つのパラメータを手動で調整した。その後、パラメータの修正が完了すると、借入上限は元の値（Core：180,000、Prime：70,000）に戻された。
補償の実行にあたっては、Chaos LabsはBuilderNetを通じて約141.5 ETHを回収し、Aave DAOのトレジャリーからの補助も得た。総補償額は約345 ETH（過去の価格を基に約87万ドル相当）に達し、すべての影響を受けたアカウントに完全に行き渡るよう設計された。このコミットメントは、技術的な失敗にもかかわらず、ユーザートラストを維持しようとするエコシステムの決意を示すものだった。
オラクル失敗から学ぶ：DeFiの清算履歴におけるパターン
この事件は孤立して起きたわけではない。DeFiエコシステムは、過去にもオラクルに関わる災害に何度も直面し、連鎖的な清算やシステム全体の損害を引き起こしてきた。2024年2月のMoonwellのオラクル誤設定では、cbETHの価格が一時的に約1ドル（市場価値は約2200ドル）と誤表示され、多額の清算と約180万ドルのプロトコルの悪債を生んだ。以前の事例には、Mango Marketsの操作攻撃やEuler Financeの脆弱性もあり、いずれも数億ドル規模の損失をもたらしている。
しかし、Aaveのケースは特に特徴的だ。従来のオラクル災害は、外部データの改ざんや価格フィードの操作に起因していたのに対し、今回は内部のセキュリティアーキテクチャに由来している点だ。特に、誤ったパラメータ設定が、もともと操作を防ぐために設計された保護層を逆に破壊的な道具に変えてしまったのである。
「コードは法なり」のパラドックス：不完全なシステムにおける教訓
DeFiの根底にある哲学は、「コードは法なり」—スマートコントラクトは人間の介入なしに自律的に実行され、透明性と信頼性を確保するというものだ。しかし、この原則には潜在的な脆弱性も含まれる。パラメータの誤設定や技術的ミスによって、悪意なくしてもコードは同じく冷徹に動作する。停止ボタンも人間の上書きも存在しないため、影響を受けたユーザーは警告もなく清算されてしまう。
Chaos Labsの補償約束は、即時の経済的損失を埋めるものだが、根本的なエンジニアリングの問題を解決するものではない。真のシステム強化には、パラメータ更新の厳格な検証、オンチェーン制約のリアルタイム整合性チェック、そして誤動作を未然に察知し管理者に警告を送る早期警戒システムの導入が必要だ。今回のAave清算事件は、迅速な対応と完全補償によって一時的に収束したものの、DeFi全体にとって重要な脆弱性を浮き彫りにした。今後、より高度な清算メカニズムや複雑な担保構造が進むにつれ、保護メカニズム自体が清算の媒介となるリスクも高まる。業界は、これらの誤りを防ぐだけでなく、主要システムの故障時にも正しく機能するフェイルセーフを設計することに取り組む必要がある。