エリック、フォーサイトニュース執筆北京時間の今日10:21頃、デルタ・ニュートラル戦略を用いて発行されたステーブルコイン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を使って2000万ドル超の資産を引き出し、ハッカーは熊市の中で自分にとっての「百倍コイン」を見つけた。再び「不注意」による抜け穴昨年10月11日の大暴落では、多くのデルタ・ニュートラル戦略を用いたステーブルコインが、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は、緊急停止は署名は一つだけで十分であり、その権限はできるだけチームメンバーや信頼できる外部運営者に分散させるべきだと提言している。こうすれば、オンチェーンの異常に対する注目度が高まり、迅速な停止の可能性も高まるし、時差のある地域間でも対応しやすくなる。単一署名だけでプロトコルを停止できるという提案はやや過激だが、実際に複数の署名を必要とする仕組みだと、緊急時に対応が遅れる可能性もある。信頼できる第三者を導入し、オンチェーンの行動を継続的に監視させるか、緊急停止権限を持つ監視ツールを使うことも、今回の事件から得られる教訓だ。
20万で約1億円を引き出す、DeFi ステーブルコイン再び攻撃を受ける
エリック、フォーサイトニュース執筆
北京時間の今日10:21頃、デルタ・ニュートラル戦略を用いて発行されたステーブルコイン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を使って2000万ドル超の資産を引き出し、ハッカーは熊市の中で自分にとっての「百倍コイン」を見つけた。
再び「不注意」による抜け穴
昨年10月11日の大暴落では、多くのデルタ・ニュートラル戦略を用いたステーブルコインが、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は、緊急停止は署名は一つだけで十分であり、その権限はできるだけチームメンバーや信頼できる外部運営者に分散させるべきだと提言している。こうすれば、オンチェーンの異常に対する注目度が高まり、迅速な停止の可能性も高まるし、時差のある地域間でも対応しやすくなる。
単一署名だけでプロトコルを停止できるという提案はやや過激だが、実際に複数の署名を必要とする仕組みだと、緊急時に対応が遅れる可能性もある。信頼できる第三者を導入し、オンチェーンの行動を継続的に監視させるか、緊急停止権限を持つ監視ツールを使うことも、今回の事件から得られる教訓だ。