撰文：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 代幣的流通量接近 3000 萬枚，最大持有者 Stream Finance 持有超過 1300 萬枚 RLP，淨風險敞口約為 1700 萬美元。
沒錯，之前因 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 的合約時，未設置最大鑄造數額，也未讓鑄造合約使用鏈上預言機進行二次驗證，便直接信任了 SERVICE_ROLE 提供的所有參數。
預防也不到位
除了推測被黑的原因，YAM 也指出了項目方在應對危機方面的準備不足。
YAM 在 X 上表示，Resolv Labs 在黑客首次攻擊完成後的 3 個小時才暫停協議，其中約 1 小時的延遲是因為收集多簽交易所需的 4 個簽名。YAM 認為，緊急暫停應只需一個簽名，且權限應盡可能分配給團隊成員或可信的外部運營人員，以提高對鏈上異常情況的關注度、加快暫停速度，並更好地覆蓋不同時區。
雖然僅需單個簽名即可暫停協議的建議有些激進，但需跨不同時區的多個簽名才能暫停協議，確實可能在緊急情況發生時耽誤大事。引入可信的、持續監控鏈上行為的第三方，或使用具有緊急暫停協議權限的監控工具，都是此次事件帶來的「後事之師」。
黑客對 DeFi 協議的攻擊早已不限於合約漏洞，Resolv Labs 的事件給項目方的警示在於：在協議安全方面的假設應是不能信任其中任何一環，所有涉及參數的環節都必須至少進行二次驗證，即使是項目方自己運營的後端也不例外。