撰文：Eric，Foresight News
北京時間今日10:21 左右，利用Delta 中性策略發行穩定幣USR 的Resolv Labs 遭到駭客攻擊。 0x04A2 開頭的位址用10 萬枚USDC 從Resolv Labs 協定中鑄造出了5000 萬枚USR。
隨著事件曝光，USR 應聲跌至0.25 美元附近，截至撰稿時回升至0.8 美元左右。 RESOLV 代幣價格短時最高跌幅也接近10%。
之後駭客如法砲制再次用10 萬枚USDC 鑄造了3000 萬枚USR。隨著USR 的大幅脫錨，套利交易者也快速行動，Morpho 上支持以USR、wstUSR 等作為抵押品的許多藉貸市場已幾乎被掏空，BNB Chain 上的Lista DAO 也暫停了新的借款請求。
受到影響的還不只這些借貸協議。 Resolv Labs 協議設計中，用戶還可以鑄造一種價格波動更大，收益也更高，但需要在協議收到損失時承擔賠償責任的RLP 代幣。目前RLP 代幣的流通量近3,000 萬枚，最大持有者Stream Finance 持有超1,300 萬枚RLP，淨風險敞口約1,700 萬美元。
沒錯，之前因為xUSD 暴雷了一次的Stream Finance 可能會再被爆擊。
截至撰文時，駭客已將USR 轉換為USDC 和USDT，並持續買入以太坊，目前已經買入超1 萬枚。用20 萬枚USDC 套出了超2000 萬美元的資產，駭客在熊市期間找到了屬於TA 的「百倍幣」。
又一次因「不嚴謹」而鑽空子
去年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 設定為5000 萬，實現了用10 萬枚USDC 鑄造5000 萬枚USR 的攻擊事件。
歸根究底，Grok 給出的結論是，Resolv 在設計協議時並未考慮用於接收用戶鑄造請求的地址（或合約）會被黑客控制的可能性，在鑄造USR 的請求提交給最後鑄造USR 的合約時，沒有設置最大鑄造數額，也沒有讓鑄造合約用鏈上預言鏈進行了二次信任，就用鏈上預言提供的所有參數。
預防也不到位
除了推測被駭的原因，YAM 也指出了專案方在應對危機方面的準備不足。
YAM 在X 上表示，Resolv Labs 在駭客第一次攻擊完成後的3 個小時才暫停了協議，其中有大約1 小時的延遲是來自於收集多簽交易所需的4 個簽名。 YAM 認為，緊急暫停應該只需一個簽名，並且權限應該盡可能分配給團隊成員，或者可信的外部運營人員，這樣可以增加對鏈上異常情況的關注度，提高快速暫停的可能性，並更好地覆蓋不同時區。
雖然只需單一簽名就可以暫停協議的建議有些激進，但需要跨不同時區的多個簽名才能暫停協議確實在緊急情況發生時可能會耽誤大事。引入可信賴的、持續監控鏈上行為的第三方，或使用有緊急暫停協議權限的監控工具，都是這次事件帶來的「後事之師」。
駭客對DeFi 協定的攻擊早就已經不限於合約漏洞，Resolv Labs 的事件給專案方的警告在於：在協定安全方面的假設應該是不能信任其中任何一環，所有涉及參數的環節都必須至少進行二次驗證，即使是專案方自己運作的後端也不例外。
