Horizon — Multisig Collapse: анатомия системной криптоатаки

Никто не нажимал «Withdraw All». Никто не писал в чаты о взломе. Интерфейсы работали — до тех пор, пока не стало поздно. Когда средства начали уходить из Horizon, это не выглядело как атака. Это выглядело как обычная работа протокола. И именно это — самый тревожный сигнал.

Контекст: что такое Horizon и почему ему верили

Horizon — инфраструктурный Web3-протокол, завязанный на управление активами через multisig-архитектуру.
Он не был «очередным DeFi-стартапом». Он был прослойкой доверия:

• использовался как операционный слой для хранения средств,
• интегрировался с dApp-ами и мостами Web3,
• служил «безопасным хранилищем» для команд и DAO.

Ему доверяли по простой причине: multisig. Модель коллективного подтверждения транзакций давно считается стандартом безопасности. Если для подписи нужно несколько ключей — значит, один сбой не приведёт к катастрофе. Так думали все.

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

В норме архитектура Horizon выглядела так:

• средства хранятся в смарт-контракте,
• любые критические операции требуют подтверждения N из M подписей,
• ключи распределены между участниками или сервисами.

На бумаге — надёжно. На практике — появилась зона, где логика контракта доверяла внешнему процессу больше, чем нужно.

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

Не в «сломанном коде». Не в баге компилятора. А в архитектурном допущении:

• часть подписей генерировалась или подтверждалась через автоматизированный слой,
• не все сигналы аномалий проверялись on-chain,
• логика «если подписи есть — значит всё ок» не учитывала контекст их появления.

То, что проигнорировали — поведенческую модель.

Момент атаки: что увидел блокчейн

Сначала — тишина.
Потом — серия транзакций, которые выглядели валидно.

On-chain данные показывали:

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

Но были детали, которые выбивались из нормы:

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

Это не выглядело как взлом. Это выглядело как слишком идеальная работа системы.

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

Когда пользователи ошибаются, on-chain это видно сразу:

• хаотичные транзакции,
• неправильные параметры,
• попытки отменить действия.

Здесь было иначе.

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

• последовательность действий без пауз на реакцию,
• отсутствие «попыток исправить»,
• полное совпадение с разрешённой логикой контракта.

Важно: Ни один пользователь не мог инициировать это в одиночку. И ни одна подпись сама по себе не была «вредоносной».

Зона подозрений начинается там, где:

• multisig перестаёт быть коллективным решением,
• а превращается в скрипт с ключами.

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

Если вы видите:

• автоматизированные подписи без on-chain delay,
• одинаковые временные паттерны у разных ключей,
• отсутствие независимого мониторинга multisig-действий, — это не удобство.

Это потенциальная криптоатака в режиме ожидания.

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

Horizon — не аномалия. Это симптом.

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

• «multisig = безопасность»,
• «если формально всё валидно — риска нет»,
• «инфраструктурные слои можно автоматизировать без последствий».

Но Web3 взрослеет, а угрозы — тоже.

Мы видим это в:

• мостах Web3,
• DAO-управлении,
• сервисных кошельках,
• кастодиальных решениях «без кастодии».

Проблема не в коде. Проблема в доверии к процессу без проверки поведения.

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

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

• те, кто хранит средства в инфраструктурных протоколах,
• те, кто не отслеживает on-chain активность контрактов.

Инвесторы

• ориентирующиеся на «бренд безопасности»,
• не анализирующие архитектуру управления.

Команды

• использующие автоматизацию подписей,
• полагающиеся на multisig как на финальный барьер.

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

• мосты Web3,
• сервисы управления активами,
• любые решения с delegated signing.

Как защититься (без иллюзий)

Это не чек-лист «как быть в безопасности навсегда». Но есть сигналы, которые нельзя игнорировать:

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

Без этого безопасность DeFi — это витрина.

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

Horizon можно было не «взламывать». Его просто использовали так, как он позволял. Этот кейс учит не бояться хакеров. Он учит бояться слишком гладких систем, где всё выглядит правильно.

Почему подобных атак станет больше?
Потому что Web3 масштабируется быстрее, чем его модели доверия.

И каждый multisig без анализа поведения — это не защита. Это отложенный риск.