На прошлой неделе блокчейн-аналитики заметили $16 млн в подозрительных переводах с адресов, связанных с CoinDCX. Биржа сразу отреагировала скептически: генеральный директор Сумит Гупта назвал это ложной тревогой. Первый ответ казался логичным — адреса действительно были старыми, созданы в январе 2025-го и скомпрометированы при взломе в июле того же года, когда биржа потеряла $44 млн. Официально биржа утверждала, что эти кошельки давно не используются.
Но хорошо известный аналитик ZachXBT разобрался детальнее. Оказалось, что один из адресов (TQKJQ) продолжал использоваться поставщиком ликвидности и ещё в апреле-мае 2026 года переводил депозиты пользователей на текущий основной горячий кошелёк биржи. То есть устаревший адрес не был мёртвой зоной — на него продолжали отправляться средства, и их нужно было перенаправить на актуальные кошельки.
Суть проблемы стала ясна позже: внутренний автоматизированный процесс, призванный миграировать все входящие депозиты со старого кошелька на новый, дал сбой. В результате пользователи продолжали отправлять средства на адрес, который формально считался неактивным, а биржа не перехватила эти транзакции. CoinDCX так и не объяснила, почему такой критичный процесс миграции остался уязвимым спустя почти год после взлома.
По итогам биржа опубликовала в блоге признание: да, произошла ошибка внутреннего процесса, да, $15,99 млн ушли безвозмездно, и биржа поглощает убыток целиком. Компания также подтвердила, что балансы пользователей, активные кошельки и торговые системы остались нетронутыми — взломаны не были. Но при этом CoinDCX признала, что могла бы раскрыть инцидент быстрее, чем это произошло на самом деле.
Это — не первая проблема CoinDCX с управлением наследием прошлых взломов. Июльский взлом 2025 года уже обошёлся дорого, и он вскрыл слабость в процедурах вывода старых инфраструктурных компонентов. Когда биржа переходит на новую инфраструктуру после взлома, весь набор старых адресов, кошельков и интеграций должен быть полностью заморожен на уровне приёма платежей — но на практике оказалось, что какие-то части системы остались в полусонном состоянии.
Для российского крипто-бизнеса этот случай — хороший пример того, почему при восстановлении после инцидента безопасности недостаточно просто «не использовать» старые адреса. Нужны явные блокировки на уровне контрактов, явные уведомления пользователям, явные проверки, что никакой автоматизированный процесс не может отправить средства в старый адрес. Если у вас есть платёжная система (как в AI Studio для автоматизации платежей на Signum/SIGNA), то после любого инцидента нужно не просто пометить старый адрес как deprecated — нужно убедиться, что все каналы, через которые туда могут придти средства, явно перенаправляют на новый адрес или отклоняют транзакцию с чётким уведомлением.
Для крупных бирж и платёжных систем это основной урок: не полагайтесь на то, что система «сама не будет использовать» старый адрес. Ищите все точки входа потока данных, явно заблокируйте их на уровне контракта или фильтра, и убедитесь, что процесс миграции никогда не будет молча игнорировать старые входящие платежи — лучше вернуть их отправителю или остановить процесс с алертом. CoinDCX заплатила $16 млн за то, чтобы выучить это на дорогом опыте.