Автор: Эрик, 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 миллионов долларов США.
Да, ранее пострадавший из-за сбоя xUSD Stream Finance может снова подвергнуться удару.
На момент написания статьи хакер конвертировал USR в USDC и USDT и продолжает покупать Ethereum, уже приобретя более 10 000 единиц. С помощью 200 000 USDC хакер вывел активы на сумму более 20 миллионов долларов США и в период медвежьего рынка нашел свой «стоикратный» токен.
Снова воспользовались пробелом из-за «небрежности»
Падение 11 октября прошлого года привело к потере залога у многих стабильных монет, использующих дельта-нейтральные стратегии, из-за ADL (автоматическое снижение плеча). Проекты, использующие альткоины в качестве активов для реализации стратегии, понесли еще более серьезные потери и некоторые вообще скрылись.
В этот раз атаке подверглась Resolv Labs, которая также использовала аналогичный механизм для выпуска USR. Проект объявил о завершении семенной серии финансирования на 10 миллионов долларов США в апреле 2025 года с участием 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 оффчейн, поэтому не было установлено никаких ограничений по верхней границе и не проводилось проверки оракулом на цепочке — сразу выполнялась mint(_mintAmount).
На основании этого YAM подозревает, что хакер получил контроль над SERVICE_ROLE, который должен был находиться под контролем команды проекта (возможно, из-за сбоя внутреннего оракула, предательства или кражи ключей), и при чеканке напрямую установил _mintAmount в 50 миллионов, что позволило осуществить атаку с чеканкой 50 миллионов USR за 100 тысяч USDC.
В конечном счете, Grok пришел к выводу, что Resolv при проектировании протокола не учел возможность того, что адрес (или смарт-контракт), предназначенный для приема запросов на чеканку пользователей, может быть скомпрометирован хакерами; при подаче запроса на чеканку USR в последний смарт-контракт для чеканки USR не было установлено максимальное количество чеканки, а также не было использовано ончейн-оракула для вторичной проверки, и все параметры, предоставленные SERVICE_ROLE, были приняты без проверки.
Профилактика также недостаточна
Помимо предположений о причинах взлома, YAM также указал на недостаточную готовность команды проекта к реагированию на кризис.
YAM на X отметил, что Resolv Labs приостановила протокол только через 3 часа после завершения первой атаки хакеров, причем около часа задержки было связано с необходимостью собрать 4 подписи для мультиподписи. YAM считает, что аварийная приостановка должна требовать только одной подписи, а права должны быть максимально распределены между членами команды или доверенными внешними операторами, чтобы повысить внимание к аномалиям в цепочке, увеличить вероятность быстрой приостановки и лучше охватить различные часовые пояса.
Хотя предложение о приостановке протокола с помощью единственной подписи кажется радикальным, требование нескольких подписей из разных часовых поясов для приостановки протокола может действительно привести к задержкам в чрезвычайных ситуациях. Введение доверенного третьего лица, постоянно отслеживающего поведение в цепочке, или использование мониторинговых инструментов с правом экстренного приостановления протокола — это «уроки после инцидента», извлеченные из этого события.
Атаки хакеров на DeFi-протоколы давно уже не ограничиваются уязвимостями смарт-контрактов; инцидент с Resolv Labs служит предупреждением для проектов: в вопросах безопасности протокола следует предполагать, что ни один из компонентов не заслуживает доверия, и все этапы, связанные с параметрами, должны проходить как минимум двойную проверку, даже если бэкенд находится в собственности самого проекта.