
流動性再質押プロトコルのKelpクロスチェーンブリッジが土曜日に攻撃を受け、攻撃者は116,500 rsETH(約2.92億ドル)を盗み、その盗難トークンをAave V3に担保として入れ、ラップドイーサ(WETH)を大量に借り入れました。Aaveプロトコルのコントラクト自体は影響を受けていないものの、今回の攻撃により台帳上で約1.96億ドルの不良債権が発生し、プラットフォームのTVLは約200億ドルまで急落しました。
攻撃の入口はAaveそのものではなく、Kelpのクロスチェーンブリッジです。土曜日、攻撃者はKelpのブリッジ接続器をだまし、116,500 rsETHを攻撃者が管理するアドレスへ解放させました。rsETHはKelpの流動性再質押の担保証明トークンで、EigenLayerを通じたルーティングにより得られる質押イーサの収益を表しています。
攻撃者はその後、盗んだrsETHをAave V3に担保として預け、WETHを借り入れました。Aaveで直接触れることのできないブリッジ層にある基礎担保が消失していたため、これらの借入ポジションは実質的に回収不能の不良債権となりました。オンチェーンデータによれば、Aaveの不良債権は約1.96億ドルで、Aave、Compound、Eulerの合計ポジションは約2.36億ドルです。
Aaveの貸出台帳は22のチェーンにまたがりますが、イーサリアムのメインチェーンでは未回収貸出178.2億ドルのうち142.4億ドルを保有しており、さらにWETHはAaveの全貸出の39.49%を占めています。今回の攻撃は、Aaveの台帳規模最大のrsETH/WETH担保による借入ペアを正確に狙い撃ちし、なぜ不良債権が高い割合で集中し、全プラットフォームに分散されなかったのかを説明しています。
Aaveの創業者Stani Kulechovは、これが外部攻撃であり、プロトコルのコントラクトは無傷だと確認しました。しかし、Aaveは担保としてrsETHを受け入れており、その基礎資産の安全性はAaveの管理範囲外のクロスチェーンブリッジに依存していました。結果として、いかなる場合でも預金者が損失リスクを負うことになりました。
Aaveは当初、Umbrella準備金があらゆる不足分を補うと述べていましたが、土曜日の午後には公式の説明が「不足分を補う方法を検討する」に軟化しており、準備規模が1.96億ドルの不良債権のギャップを完全にカバーできない可能性を示しています。
もしUmbrella準備金が損失を完全にカバーできない場合、Aaveの設計メカニズムに従い、stkAAVE(ステーキング中のAAVEトークン)保有者は損失の一部を負担する必要が生じる可能性があります。これは、AAVEトークンが今回の出来事で16%下落圧力を受けた深い理由の一つです。
今回の出来事から得られる核心的な教訓は、KelpとAaveそのものの範囲を超えています。流動性再質押トークン(LRT)は、すべての主要なDeFi貸出プロトコルによって担保ホワイトリストに載せられています。理由は、収益属性があり、かつイーサリアムにロックされた価値の割合がますます大きくなることを表すためです。しかし、LRTの価格付けに用いられる既存のリスクモデルは、それが通常の市場条件下でアンカー(連動)された価値を維持する前提を置いており、基礎となるブリッジが攻撃され、担保が瞬時にゼロになるという極端なシナリオを織り込んでいません。
トレーダーAltcoin SherpaはXで次のように指摘しています。「AAVEはDeFiの柱であり、数十億ドルの資金を内包しています。AAVEに感染(伝染)のリスクが発生するとき、それはシステム全体の脆弱性を示しています。」
いいえ。Aaveの創業者Stani Kulechovは、今回が外部攻撃であり、Aaveのスマートコントラクトは無傷であることを明確に述べています。不良債権の発生は、Aaveが担保としてrsETHを受け入れたことに起因します。そして、その基礎資産が、Aaveが到達できないKelpのクロスチェーンブリッジで攻撃を受けた後に消失したため、関連する貸出ポジションが回収不能の不良債権となりました。
UmbrellaはAaveのセキュリティモジュールで、プロトコルの不良債権の不足に対処するために設計されています。準備金で損失を完全に補えない場合、stkAAVE保有者(つまり、ステーキングしているAAVEトークンのユーザー)が最後の防衛線として、不足分を補うためにステーキングトークンが削減(Slashing)される可能性があります。今回の出来事では、Umbrella準備で1.96億ドルの不良債権をカバーできるかどうかは依然として不確実であり、これがAAVEトークンが今回大きく承圧された核心的な理由です。
今回の出来事は、LRTタイプの担保のシステム的な盲点を明らかにしました。貸出プロトコルが広くLRTを担保として受け入れている一方で、実際にはブリッジの安全性リスクが貸出台帳に持ち込まれています。ブリッジのいかなる協定でも安全上の失敗が起きれば、関連するLRTを受け入れている貸出プロトコルに想定外の不良債権が発生する可能性があります。これは、各DeFiプロトコルがLRT担保のリスクモデル、担保率、ポジション上限を改めて再評価する必要があることを意味します。
関連記事