Обміняти 200 000 на майже 100 мільйонів: стабільні монети DeFi знову зазнали атаки

Автор: Еріке, Foresight News

О 10:21 за пекинським часом сьогодні приблизно, Resolv Labs, яка випустила стейблкоїн USR, використовуючи дельта-нейтральну стратегію, зазнала хакерської атаки. Адреса, що починається з 0x04A2, випустила 50 мільйонів USR із протоколу Resolv Labs, використавши 100 000 USDC.

Після того як про подію стало відомо, USR одразу впав приблизно до рівня 0,25 долара, а на момент підготовки матеріалу повернувся приблизно до 0,8 долара. Курс токена RESOLV у короткостроковому періоді також показав максимальне падіння, яке наближалось до 10%.

Після цього хакери повторили схему: знову випустили 30 мільйонів USR, використавши 100 000 USDC. Після того як USR суттєво відійшов від прив’язки, арбітражники швидко підключилися; багато кредитних ринків на Morpho, де як заставу використовують USR, wstUSR та інші активи, майже повністю спорожніли, а Lista DAO на BNB Chain призупинив нові заявки на позики.

Постраждали не лише ці кредитні протоколи. У проєктній архітектурі протоколу Resolv Labs користувачі також можуть карбувати токен RLP — він має більшу амплітуду цінових коливань і вищу дохідність, але вимагає компенсаційної відповідальності, коли протокол зазнає збитків. Наразі обсяг обігу токена RLP становить майже 30 мільйонів одиниць; найбільший власник Stream Finance тримає понад 13 мільйонів RLP, а чиста ризикова експозиція — приблизно 17 мільйонів доларів.

Так, Stream Finance, який уже одного разу постраждав через xUSD, імовірно, може знову бути вражений.

Станом на момент підготовки матеріалу хакери конвертували USR у USDC та USDT і продовжують купувати Ethereum; на даний момент вони вже придбали понад 10 000 токенів. Використавши 200 000 USDC, вони забезпечили отримання активів більш ніж на 20 мільйонів доларів — у ведмежому ринку хакери знайшли «монету в 100 разів», свою для TA.

Ще раз використали лазівку через «недостатню ретельність»

Падіння 11 жовтня минулого року призвело до того, що багато стейблкоїнів, які випускали за дельта-нейтральними стратегіями, зазнали втрати застави через ADL (автоматичне зниження плеча). Деякі проєкти, які використовують альткоїни як частину стратегії виконання, втратили ще більше — аж до того, що просто зникли.

Цього разу Resolv Labs, на який напали, також випускає USR за подібним механізмом. Раніше цей проєкт у квітні 2025 року оголосив про завершення посівного раунду на 10 мільйонів доларів, де лідерами виступили Cyber.Fund та Maven11, а участь брали Coinbase Ventures; а наприкінці травня — на початку червня запустив токен RESOLV.

Але причина атаки на Resolv Labs — не екстремальна ринкова ситуація, а «недостатньо ретельно продуманий» механізм емісії USR.

Наразі ще немає аналізу від жодної безпекової компанії або офіційної сторони щодо причин цієї хакерської атаки. DeFi-спільнота YAM, проаналізувавши ситуацію, попередньо дійшла висновку: атаку, найімовірніше, спричинило те, що хакери захопили SERVICE_ROLE, який протокол використовує в бекенді для надання параметрів карбувальному контракту.

Згідно з аналізом Grok, коли користувач карбує USR, він ініціює запит у мережі та викликає функцію requestMint контракту; параметри включають:

_depositTokenAddress: адресу токена, який вносять;

_amount: суму, яку вносять;

_minMintAmount: мінімальну очікувану кількість USR, яку мають отримати (від ковзання).

Після цього користувач вносить у контракт USDC або USDT. Бекенд проєкту SERVICE_ROLE відстежує запити; за допомогою оракулу Pyth перевіряється вартість внесених активів. Після цього викликаються функції completeMint або completeSwap, щоб визначити фактичну кількість USR, яка буде випущена.

Проблема в тому, що карбувальний контракт повністю довіряє _mintAmount, яке надає SERVICE_ROLE. Він вважає, що це число було перевірено Pyth поза ланцюгом, тому не встановлює жодних обмежень зверху і не виконує перевірку оракулом on-chain; просто одразу виконує mint(_mintAmount).

На цій основі YAM припускає, що хакери захопили SERVICE_ROLE, який мав контролюватися командою проєкту (можливо, через втрату контролю над внутрішнім оракулом, крадіжку «наглядачем» або викрадення ключів). Під час карбування вони одразу встановили _mintAmount на 50 мільйонів, реалізувавши атаку: за допомогою 100 000 USDC карбували 50 мільйонів USR.

Зрештою, висновок Grok полягає в тому, що Resolv під час розробки протоколу не врахував можливість захоплення хакерами адреси (або контракту), які використовуються для приймання запитів користувачів на карбування. Коли запит на карбування USR подається в контракт, який здійснює фінальну емісію USR, не встановлюється максимальна кількість для карбування, і карбувальний контракт не проводить повторну on-chain верифікацію за допомогою оракулів, а просто довіряє всім параметрам, які надає SERVICE_ROLE.

Профілактика теж була не на рівні

Окрім припущень щодо причин злому, YAM також вказує на недостатню підготовленість команди проєкту до реагування на кризу.

На X YAM зазначила, що Resolv Labs призупинив протокол лише через 3 години після завершення першої атаки з боку хакерів, а приблизно 1 година затримки була пов’язана зі збором 4 підписів, необхідних для мультипідпису. YAM вважає, що в разі надзвичайної ситуації для зупинки має бути достатньо одного підпису, а повноваження слід максимально розподілити між членами команди або довіреними зовнішніми операторами — це підвищує уважність до аномальної поведінки в мережі, збільшує ймовірність швидкої зупинки та краще охоплює різні часові пояси.

Хоча рекомендація, що для зупинки протоколу достатньо одного підпису, звучить трохи надто радикально, факт лишається фактом: вимога отримати кілька підписів із різних часових поясів, щоб призупинити протокол, справді може затягнути важливі рішення в момент, коли виникає надзвичайна ситуація. Залучення довіреної третьої сторони, яка постійно моніторить поведінку в мережі, або використання моніторингових інструментів із правом на екстрену зупинку — усе це є «уроком на майбутнє», який винісся з цього інциденту.

Атаки на DeFi-протоколи здавна вже не обмежуються лише вразливостями контрактів. Інцидент Resolv Labs слугує попередженням для команд: у припущеннях щодо безпеки протоколу не можна довіряти жодному елементу; всі етапи, що стосуються параметрів, мають мінімум разів двічі проходити верифікацію, навіть якщо йдеться про бекенд, яким управляє сама команда проєкту.