Обмін 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 також призупинила нові запити на отримання кредитів.

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

Дійсно, Stream Finance, який раніше постраждав від інциденту з xUSD, може знову постраждати.

На момент написання статті хакер конвертував USR в USDC і USDT і продовжує купувати Ethereum, вже купивши понад 10 000. За допомогою 200 000 USDC вони вилучили активи на суму понад 20 мільйонів доларів, знайшовши свою "стократну монету" під час ведмежого ринку.

Інше експлуатаційне порушення через «недостатню суворість»

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

Атаковані Resolv Labs також випустили USR за допомогою подібного механізму. У квітні 2025 року проект оголосив про завершення стартового раунду фінансування в розмірі 10 мільйонів доларів під керівництвом Cyber.Fund і Maven11 за участю Coinbase Ventures, а токени RESOLV були запущені в кінці травня - на початку червня.

Однак причиною атаки на Resolv Labs стали не екстремальні ринкові умови, а скоріше «відсутність строгості» в проектуванні механізму карбування USR.

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

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

_depositTokenAddress: адреса депозитного токена;

_amount: сума депозиту;

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

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

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

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

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

Заходи запобігання також були недостатніми

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

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

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

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