DxSale выпускает разъяснение инцидента: контракты v2 и более поздних версий для блокировки ликвидности не пострадали
DxSale выпускает разъяснение инцидента: контракты v2 и более поздних версий для блокировки ликвидности не пострадали
Недавняя эксплуатация блокировщика ликвидности в сети BNB Chain вновь подняла старый вопрос в сфере DeFi: может ли «старая инфраструктура» снова стать опасной по мере эволюции базовой сети? В конце мая 2026 года злоумышленники нацелились на устаревшие блокировщики ликвидности DxSale, датируемые 2021 годом, инициировав перемещение средств в сети и вызвав волну беспокойства среди проектов, которые когда-то полагались на раннюю архитектуру блокировки DxSale.
В последующем разъяснении, опубликованном примерно 30–31 мая 2026 года (в зависимости от часового пояса), DxSale заявила, что проблема изолирована и затрагивает только ее контракт блокировки v1. При этом версии v2 и более поздние (v2, v3 и т. д.) не пострадали, поскольку более поздние контракты прошли аудит, а заблокированные активы пользователей остались в безопасности.
Ниже представлен практический анализ произошедшего, причин, по которым «атомарное» выполнение операций на уровне сети может выявлять крайние случаи в старых контрактах, и того, что следует предпринять поставщикам ликвидности (LP) и командам токенов.
Что произошло в сети BNB Chain (29 мая 2026 г.)
29 мая 2026 года появились сообщения о том, что примерно 1400 старых позиций LP — в основном из эпохи 2021 года — были опустошены в сети BNB Chain, а предполагаемые убытки составили около 7,3 миллиона долларов. Несколько аналитических материалов, отслеживающих инцидент, отметили, что злоумышленник использовал подход, соответствующий манипуляции с правами владения/привилегированным контролем, а затем перенаправлял активы через свопы и депозиты.
Широко цитируемый адрес злоумышленника в инциденте:
- 0xC4574DDE...2EeaFA69 — доступен для просмотра на BscScan (отслеживание адресов)
Публичные сводки также описывали, как злоумышленник консолидировал средства в BNB, перевел 2958 BNB (приблизительно 1,87 млн долларов на тот момент) на два основных кошелька, а затем перенаправил их на депозитные адреса бирж и совершил свопы через PancakeSwap. Для доступного обзора инцидента см. отчет Cointelegraph, зеркально отображенный на TradingView.
Основной тезис DxSale: зона поражения — только v1
В разъяснении DxSale подчеркиваются три ключевых утверждения:
- Затронуты контракты ранней версии «v1» для блокировки ликвидности, запущенные в 2021 году.
- Контракты v2 и более поздних версий не пострадали.
- Контракты более поздних поколений были разработаны на основе другой архитектуры и прошли проверку безопасности/аудит.
Хотя пользователи всегда должны проверять адреса контрактов и объем аудита для своих конкретных блокировок, вы можете проверить историю безопасности проектов и аудитов DxSale на странице проекта DxSale на CertiK Skynet.
Для пользователей, незнакомых с версионированием в DxSale, собственная документация DxSale проводит различие между более новыми блокировщиками (например, документация по блокировке ликвидности DxLock V2), что помогает при подтверждении того, какие инструменты и генерация контрактов использовались конкретным проектом.
Почему «атомарные транзакции» могут нарушать старые предположения
DxSale назвала первопричиной проблему совместимости между новым стилем выполнения «атомарных транзакций» в сети BNB Chain и ранней конструкцией блокировщика v1.
В современных экосистемах EVM термин «атомарный» часто относится к объединению нескольких действий в одну транзакцию типа «всё или ничего» (так что промежуточные состояния никогда не сохраняются). Это направление ускорилось в 2025–2026 годах благодаря более широкому внедрению абстракции учетных записей и примитивов пакетной обработки, включая механизмы в стиле EIP-7702.
BNB Chain публично обсуждала обновления смарт-кошельков и абстракции учетных записей — см. анонс хардфорка Pascal в сети BNB Chain. Базовый стандарт, популяризировавший концепции делегирования/пакетной обработки в рамках одной транзакции, см. EIP-7702 на Ethereum EIPs.
Ключевой урок для безопасности DeFi
Даже когда устаревший контракт «работал годами», новые шаблоны транзакций могут ставить под сомнение старые модели угроз, особенно если контракт полагался на административные привилегии, необычные потоки владения или предположения о том, как можно комбинировать вызовы.
Это одна из причин, по которой в обсуждениях безопасности DeFi в 2025–2026 годах все больше внимания уделяется:
- риску неизменяемых (immutable) vs. обновляемых (upgradeable) контрактов,
- привилегированным ролям и границам владения,
- и тому, остаются ли контракты безопасными в условиях новых функций сети и сред выполнения.
Что следует предпринять поставщикам ликвидности и командам токенов сейчас
1) Подтвердите, какую версию блокировщика использовал ваш LP
Если вы являетесь членом сообщества старого проекта в сети BNB Chain, не предполагайте, что «заблокировано» означает «безопасно». Попросите команду предоставить:
- точный адрес контракта блокировщика,
- ID блокировки / страницу блокировки,
- и подтверждение того, является ли это v1 или v2+.
Если у вас есть только адрес, начните с BscScan и изучите время создания контракта, функции владения и историю транзакций.
2) Рассматривайте «аудит» как необходимое, но недостаточное условие
Аудиты снижают риск, но не устраняют его — особенно когда поведение сети развивается. Используйте ссылки на аудиты как отправную точку, а затем оцените:
- Присутствуют ли еще привилегированные функции?
- Можно ли изменить права владения?
- Есть ли контролируемые администратором параметры, влияющие на вывод средств?
3) Предполагайте, что злоумышленники будут нацеливаться на забытые контракты
Эксплуатация иллюстрирует повторяющийся паттерн: злоумышленники часто охотятся за «спящей» ликвидностью и устаревшими контрактами, поскольку мониторинг ослаблен, а меры реагирования — медленнее.
4) Защитите свои ключи подписи во время миграций и экстренных действий
Подобные инциденты часто вызывают «срочные миграции», которые являются идеальным временем для фишинга и вредоносных запросов на подпись.
Аппаратный кошелек, такой как OneKey, может помочь, храня приватные ключи в автономном режиме и требуя подтверждения транзакций на устройстве — снижая вероятность того, что скомпрометированный компьютер или расширение браузера молча подпишет вредоносные разрешения. Это не исправит уязвимый контракт DeFi, но материально улучшит личную оперативную безопасность при работе с dApps под давлением.
Итог
- Инцидент в мае 2026 года подчеркивает, как устаревшие контракты для блокировки ликвидности могут снова стать системным риском — особенно в быстро развивающихся сетях, где функции выполнения быстро эволюционируют.
- Заявление DxSale позиционирует проблему как изолированную для блокировщиков v1 эпохи 2021 года, а контракты v2 и более поздних версий не пострадали.
- Для пользователей и команд практический вывод заключается в том, чтобы инвентаризировать старые блокировки, проверять версии контрактов и обновлять практики безопасности в соответствии с реалиями 2026 года: пакетная обработка, делегированное выполнение и быстро меняющиеся тактики злоумышленников.
Если вы управляете казначейством или регулярно подписываете транзакции DeFi в сети BNB Chain, рассмотрите возможность использования OneKey как части более широкой стратегии безопасности: изоляция ключей на аппаратном уровне, тщательное управление разрешениями и спокойные, проверяемые рабочие процессы реагирования на инциденты.
