_執筆者：Eric、Foresight News_北京時間の今日10:21頃、Deltaのニュートラル戦略を用いて発行されたステーブルコインUSRを狙ったResolv Labsがハッキング被害に遭った。0x04A2で始まるアドレスが、10万枚のUSDCを使ってResolv Labsのプロトコルから5千万枚のUSRを鋳造した。事件が明るみに出ると、USRは一時0.25ドル付近まで急落し、執筆時点では約0.8ドルに回復している。RESOLVトークンの価格も短時間で最大約10％の下落を記録した。その後、ハッカーは同様の手口で再び10万枚のUSDCを用いて3千万枚のUSRを鋳造した。USRの大きな価格乖離に伴い、アービトラージ取引者も迅速に動き、Morpho上の多くの借入市場ではUSRやwstUSRなどを担保とした貸付がほぼ空になり、BNBチェーン上のLista DAOも新たな借入リクエストを停止した。影響を受けたのはこれだけの借入プロトコルだけではない。Resolv Labsのプロトコル設計には、ユーザーがより大きな価格変動と高い収益を狙えるが、損失が発生した場合に補償責任を負うRLPトークンも鋳造可能となっている。現在、RLPの流通量は約3000万枚に近く、最大保有者のStream Financeは1300万枚超を保有し、純リスクエクスポージャーは約1700万ドルにのぼる。そう、以前xUSDの暴落で大きな損失を出したStream Financeが、またもや大打撃を受ける可能性が出てきた。執筆時点で、ハッカーはUSRをUSDCやUSDTに変換し、イーサリアムを継続的に買い増しており、すでに1万枚超を購入している。20万枚のUSDCを使って2,000万ドル超の資産を引き出し、ハッカーは熊市の中で自分だけの「百倍コイン」を見つけた。### 「不注意」から再び穴を突かれる昨年10月11日の大暴落により、多くのDeltaニュートラル戦略を用いたステーブルコインは、ADL（自動レバレッジ低減）による担保損失を被った。特に、アルトコインを戦略の一環として用いたプロジェクトは損失が甚大で、最終的に撤退した例も多い。今回攻撃を受けたResolv Labsも、類似の仕組みを用いてUSRを発行していた。同プロジェクトは2025年4月に、Cyber.FundとMaven11がリードし、Coinbase Venturesも出資した1000万ドルのシードラウンドを完了したと発表し、5月末から6月初めにかけてトークンRESOLVをローンチした。しかし、Resolv Labsが攻撃を受けた原因は、市場の極端な動きではなく、USRの鋳造メカニズムの「設計の不備」にあった。現時点では、安全性を専門とする企業や公式側から、このハッキング事件の原因についての分析は出ていない。DeFiコミュニティのYAMは、初期の分析から次の結論を導き出している：攻撃は、鋳造コントラクトにパラメータを提供するためのバックエンドのSERVICE_ROLEがハッカーに制御されたことに起因している可能性が高い。Grokの分析によると、ユーザーがUSRを鋳造する際には、オンチェーン上でリクエストを発行し、コントラクトのrequestMint関数を呼び出す。パラメータは以下の通り：_depositTokenAddress：預入るトークンのアドレス；_amount：預入量；_minMintAmount：期待される最小USR受取量（スリッページ防止用）。その後、ユーザーはUSDCまたはUSDTをコントラクトに預入れ、プロジェクト側のバックエンドのSERVICE_ROLEがリクエストを監視し、Pythのオラクルを用いて預入資産の価値を確認。その後、completeMintまたはcompleteSwap関数を呼び出し、実際に鋳造されるUSRの量を決定する。問題は、鋳造コントラクトが完全にSERVICE_ROLEが提供する_mintAmountを信用し、その数字がオフチェーンのPythによって検証済みとみなしている点にある。したがって、上限設定やオンチェーンのオラクルによる二次検証を行わず、直接mint(_mintAmount)を実行してしまった。これにより、YAMはハッカーが本来プロジェクト側が制御すべきSERVICE_ROLEを制御し（内部のオラクルの失敗、内部の盗用、または鍵の盗難などが原因と推測）、鋳造時に直接_mintAmountを5千万に設定し、10万枚のUSDCで5千万USRを鋳造する攻撃を実現したと疑っている。結局のところ、Grokの結論は、Resolvがプロトコル設計時に、ユーザーの鋳造リクエストを受け付けるアドレス（またはコントラクト）がハッカーに制御される可能性を考慮していなかった点にある。USRの鋳造リクエストが最終的にUSRを鋳造するコントラクトに渡される際に、最大鋳造量の設定や、オンチェーンのオラクルによる二次検証を行わず、SERVICE_ROLEが提供するすべてのパラメータをそのまま信用してしまった。### 予防策も不十分被害の原因推測に加え、YAMはプロジェクト側の危機対応の準備不足も指摘している。YAMはX上で、Resolv Labsはハッカーによる最初の攻撃から3時間後にやっとプロトコルを停止したと述べている。この遅れの約1時間は、多署名取引に必要な4つの署名を集めるのに時間がかかったためだ。YAMは、緊急停止は署名は一つだけで十分であり、その権限はできるだけチームメンバーや信頼できる外部運営者に分散すべきだと考えている。こうすれば、オンチェーンの異常に対する注視が高まり、迅速な停止の可能性も高まる。さらに、異なるタイムゾーンの担当者間での連携も強化できる。単一署名での緊急停止を推奨するのはやや過激だが、実際に複数のタイムゾーンの署名を必要とする仕組みは、緊急時に対応が遅れるリスクも伴う。信頼できる第三者による継続的なオンチェーン監視や、緊急停止権限を持つ監視ツールの導入は、今回の事件から得られる教訓だ。DeFiのプロトコルに対する攻撃は、もはやコントラクトの脆弱性だけにとどまらない。Resolv Labsの事件は、プロジェクト側にとっての警鐘となる：プロトコルの安全性に関する仮定は、どの部分も信用してはならず、パラメータに関わるすべての要素は少なくとも二次検証を行う必要がある。たとえ自社運営のバックエンドであっても例外ではない。
20万で約1億円を引き出す、DeFi ステーブルコイン再び攻撃を受ける
執筆者：Eric、Foresight News
北京時間の今日10:21頃、Deltaのニュートラル戦略を用いて発行されたステーブルコインUSRを狙ったResolv Labsがハッキング被害に遭った。0x04A2で始まるアドレスが、10万枚のUSDCを使ってResolv Labsのプロトコルから5千万枚のUSRを鋳造した。
事件が明るみに出ると、USRは一時0.25ドル付近まで急落し、執筆時点では約0.8ドルに回復している。RESOLVトークンの価格も短時間で最大約10％の下落を記録した。
その後、ハッカーは同様の手口で再び10万枚のUSDCを用いて3千万枚のUSRを鋳造した。USRの大きな価格乖離に伴い、アービトラージ取引者も迅速に動き、Morpho上の多くの借入市場ではUSRやwstUSRなどを担保とした貸付がほぼ空になり、BNBチェーン上のLista DAOも新たな借入リクエストを停止した。
影響を受けたのはこれだけの借入プロトコルだけではない。Resolv Labsのプロトコル設計には、ユーザーがより大きな価格変動と高い収益を狙えるが、損失が発生した場合に補償責任を負うRLPトークンも鋳造可能となっている。現在、RLPの流通量は約3000万枚に近く、最大保有者のStream Financeは1300万枚超を保有し、純リスクエクスポージャーは約1700万ドルにのぼる。
そう、以前xUSDの暴落で大きな損失を出したStream Financeが、またもや大打撃を受ける可能性が出てきた。
執筆時点で、ハッカーはUSRをUSDCやUSDTに変換し、イーサリアムを継続的に買い増しており、すでに1万枚超を購入している。20万枚のUSDCを使って2,000万ドル超の資産を引き出し、ハッカーは熊市の中で自分だけの「百倍コイン」を見つけた。
「不注意」から再び穴を突かれる
昨年10月11日の大暴落により、多くのDeltaニュートラル戦略を用いたステーブルコインは、ADL（自動レバレッジ低減）による担保損失を被った。特に、アルトコインを戦略の一環として用いたプロジェクトは損失が甚大で、最終的に撤退した例も多い。
今回攻撃を受けたResolv Labsも、類似の仕組みを用いてUSRを発行していた。同プロジェクトは2025年4月に、Cyber.FundとMaven11がリードし、Coinbase Venturesも出資した1000万ドルのシードラウンドを完了したと発表し、5月末から6月初めにかけてトークンRESOLVをローンチした。
しかし、Resolv Labsが攻撃を受けた原因は、市場の極端な動きではなく、USRの鋳造メカニズムの「設計の不備」にあった。
現時点では、安全性を専門とする企業や公式側から、このハッキング事件の原因についての分析は出ていない。DeFiコミュニティのYAMは、初期の分析から次の結論を導き出している：攻撃は、鋳造コントラクトにパラメータを提供するためのバックエンドのSERVICE_ROLEがハッカーに制御されたことに起因している可能性が高い。
Grokの分析によると、ユーザーがUSRを鋳造する際には、オンチェーン上でリクエストを発行し、コントラクトのrequestMint関数を呼び出す。パラメータは以下の通り：
_depositTokenAddress：預入るトークンのアドレス；
_amount：預入量；
_minMintAmount：期待される最小USR受取量（スリッページ防止用）。
その後、ユーザーはUSDCまたはUSDTをコントラクトに預入れ、プロジェクト側のバックエンドのSERVICE_ROLEがリクエストを監視し、Pythのオラクルを用いて預入資産の価値を確認。その後、completeMintまたはcompleteSwap関数を呼び出し、実際に鋳造されるUSRの量を決定する。
問題は、鋳造コントラクトが完全にSERVICE_ROLEが提供する_mintAmountを信用し、その数字がオフチェーンのPythによって検証済みとみなしている点にある。したがって、上限設定やオンチェーンのオラクルによる二次検証を行わず、直接mint(_mintAmount)を実行してしまった。
これにより、YAMはハッカーが本来プロジェクト側が制御すべきSERVICE_ROLEを制御し（内部のオラクルの失敗、内部の盗用、または鍵の盗難などが原因と推測）、鋳造時に直接_mintAmountを5千万に設定し、10万枚のUSDCで5千万USRを鋳造する攻撃を実現したと疑っている。
結局のところ、Grokの結論は、Resolvがプロトコル設計時に、ユーザーの鋳造リクエストを受け付けるアドレス（またはコントラクト）がハッカーに制御される可能性を考慮していなかった点にある。USRの鋳造リクエストが最終的にUSRを鋳造するコントラクトに渡される際に、最大鋳造量の設定や、オンチェーンのオラクルによる二次検証を行わず、SERVICE_ROLEが提供するすべてのパラメータをそのまま信用してしまった。
予防策も不十分
被害の原因推測に加え、YAMはプロジェクト側の危機対応の準備不足も指摘している。
YAMはX上で、Resolv Labsはハッカーによる最初の攻撃から3時間後にやっとプロトコルを停止したと述べている。この遅れの約1時間は、多署名取引に必要な4つの署名を集めるのに時間がかかったためだ。YAMは、緊急停止は署名は一つだけで十分であり、その権限はできるだけチームメンバーや信頼できる外部運営者に分散すべきだと考えている。こうすれば、オンチェーンの異常に対する注視が高まり、迅速な停止の可能性も高まる。さらに、異なるタイムゾーンの担当者間での連携も強化できる。
単一署名での緊急停止を推奨するのはやや過激だが、実際に複数のタイムゾーンの署名を必要とする仕組みは、緊急時に対応が遅れるリスクも伴う。信頼できる第三者による継続的なオンチェーン監視や、緊急停止権限を持つ監視ツールの導入は、今回の事件から得られる教訓だ。
DeFiのプロトコルに対する攻撃は、もはやコントラクトの脆弱性だけにとどまらない。Resolv Labsの事件は、プロジェクト側にとっての警鐘となる：プロトコルの安全性に関する仮定は、どの部分も信用してはならず、パラメータに関わるすべての要素は少なくとも二次検証を行う必要がある。たとえ自社運営のバックエンドであっても例外ではない。