Multisig Governance Hack: как можно украсть протокол, не взламывая смарт-контракт

В блокчейне не было эксплойта. Код не ломали. Аудит не «пропустил критическую дыру». И всё же — протокол перестал принадлежать своим пользователям. Средства начали двигаться «законно», по правилам, которые никто не менял в коде. Вопрос не в том, взломали ли систему. Вопрос в том, кто на самом деле контролировал её в момент, когда это стало важно.

Это расследование — не про баг. Это про то, как в Web3 можно потерять протокол, не нарушив ни одной строчки смарт-контракта.

Контекст: что это был за протокол и почему ему доверяли

Речь идёт о типичном инфраструктурном DeFi-протоколе среднего масштаба. Не скам, не анонимная команда, не экспериментальный MVP. Проект существовал достаточно долго, чтобы заслужить доверие рынка.

У него были:

• аудит от известной фирмы;
• TVL в сотнях миллионов на пике;
• интеграции с кошельками, агрегаторами и мостами Web3;
• DAO-риторика, governance-токен и публичные обсуждения.

Пользователи доверяли не обещаниям, а процессу. Казалось, что контроль распределён, решения принимаются коллективно, а критические функции защищены multisig-механизмом.

Именно это и стало проблемой.

Техническая архитектура (упрощённо, но точно)

Как всё должно было работать

Ключевые параметры протокола — апгрейды, паузы, управление казной — контролировались через multisig.
Формально это выглядело надёжно:

• N подписантов
• M из N требуется для действия
• Подписанты — core-команда, советники, иногда DAO-представители

Multisig считался «страховкой от одиночного злоупотребления». Если один ключ скомпрометирован — этого недостаточно.

Где была реальная уязвимость

Уязвимость была не в коде, а в архитектуре управления:

• одни и те же люди контролировали и governance, и multisig;
• часть подписантов была номинальной;
• ротация ключей отсутствовала или была формальной;
• off-chain договорённости имели больший вес, чем on-chain процессы.

Multisig стал не механизмом децентрализации, а узким горлышком доверия.

Что проигнорировали

• корреляцию между ключами (одна инфраструктура, одни устройства);
• риск «тихого консенсуса» без публичного голосования;
• отсутствие таймлоков на критические операции.

Код был безопасен. Контроль — нет.

Момент атаки: когда «всё пошло по плану»

События развивались не резко. Не было «чёрного лебедя» или мгновенного дренажа.

On-chain это выглядело почти скучно:

• стандартные multisig-транзакции;
• валидные подписи;
• отсутствие revert’ов или аномальных gas-паттернов.

Но внимание привлекло другое.

Первые странности

• действия происходили в низколиквидные часы;
• несколько решений были приняты подряд, без обсуждений;
• параметры менялись в рамках допустимого, но в пользу одной стороны.

Это не выглядело как паника. Это выглядело как холодный, последовательный контроль.

On-chain логика: почему это не «ошибка пользователя»

On-chain анализ показывает не только что произошло, но и как это делали.

Характерные паттерны

• консолидация контроля перед финансовыми действиями;
• синхронность подписей без задержек;
• отсутствие внешнего сопротивления (нет отклонённых транзакций);
• аккуратное соблюдение лимитов, чтобы не триггерить алерты.

Это не похоже на взлом одного ключа. И не похоже на случайную ошибку.

Где начинается зона подозрений

Когда:

• governance де-факто отключено, но де-юре активно;
• multisig действует быстрее, чем DAO успевает реагировать;
• решения необратимы, но формально легитимны.

В этот момент протокол уже потерян, даже если средства ещё на месте.

Системная ошибка, а не единичный кейс

Это расследование не уникально. Оно просто хорошо задокументировано.

Один и тот же паттерн повторяется:

• мосты Web3;
• L2-решения;
• DAO-казначейства;
• oracle-инфраструктура.

Повторяющиеся архитектурные проблемы

• multisig как «чёрный ящик»;
• governance без реального veto;
• отсутствие прозрачной модели угроз;
• вера в аудит вместо анализа управления.

Web3 часто децентрализует код, но централизует контроль.

Кто в зоне риска

Пользователи

• думают, что «код — закон»;
• не отслеживают governance-активность;
• реагируют уже после факта.

Инвесторы

• смотрят на TVL и аудит;
• не анализируют распределение ключей;
• переоценивают DAO-структуры.

Команды

• откладывают децентрализацию «на потом»;
• используют multisig как компромисс;
• недооценивают репутационные последствия.

Инфраструктурные проекты

• становятся точкой концентрации рисков;
• часто не готовы к форензике после инцидента.

ВНИМАНИЕ: красные флаги

• multisig без таймлока;
• одни и те же люди в governance и multisig;
• редкие, но «пакетные» изменения параметров;
• отсутствие публичных post-mortem после инцидентов.

Если вы видите это — риск уже системный.

Как можно было защититься (без иллюзий)

• разделение governance и исполнения;
• обязательные задержки на критические операции;
• мониторинг multisig как attack surface;
• публичные ключевые роли и ротация.

Это не панацея. Но это снижает вероятность «тихого захвата».

Вывод без морализаторства

Этот кейс не про злодеев. Он про иллюзию децентрализации.

Смарт-контракты могут быть безупречны. А система — уязвимой.

Мы увидим больше таких атак:

• потому что они дешевле;
• потому что они легальны on-chain;
• потому что рынок всё ещё смотрит на код, а не на контроль.

Web3 взрослеет не тогда, когда меньше взломов. А тогда, когда мы начинаем задавать правильные вопросы до инцидента.

Если после этого текста вы стали смотреть на multisig не как на защиту, а как на точку риска —
значит, расследование было не зря.