Мониторинг смарт-контрактов и кошельков: алерты и автопауза

Мониторинг смарт-контрактов — это постоянное наблюдение за событиями и транзакциями ваших контрактов и кошельков с алертами людям и, в крайнем случае, автоматической паузой. Он не предотвращает ошибку в коде, но сокращает время между началом атаки и реакцией. В крупных инцидентах счёт идёт на минуты: вечером 29 октября 2026 года, по данным FinanceFeeds и The Block, основной вывод с горячих кошельков Binance — около $3,3 млрд по оценке Blockaid — занял меньше часа (данные на 30.10.2026, 01:30 МСК, ситуация развивается; Binance к этому времени не подтвердила влияние на средства пользователей).

Что отслеживать

Уровни алертов

Автоматическая пауза

Если в контракте есть функция паузы, мониторинг может вызвать её сам при срабатывании правила. Это мощный инструмент, и ему нужны ограничения.

• Адрес, который ставит на паузу, может только ставить на паузу. Снять паузу — только мультиподпись.
• Ключ этого адреса хранится в отдельном сервисе, а не на сервере приложения.
• Правила автопаузы — узкие и с высокой уверенностью: смена администратора, вывод больше X за Y минут.
• Каждая автопауза сопровождается звонком людям и записью причины.
• Пользователям заранее объяснено, что пауза существует, кто её включает и когда.

Пауза — тоже риск: злоумышленник, получивший адрес паузы, может остановить ваш продукт. Поэтому права разделяют, а снятие паузы требует нескольких подписей.

Как построить мониторинг: план

1. Составьте список контрактов и кошельков: адреса, сети, роли, ожидаемые суммы.
2. Для каждого опишите нормальное поведение: какие операции, какие объёмы, какие получатели.
3. Выберите источники данных: собственный узел или надёжный провайдер, плюс резервный.
4. Напишите правила для событий и порогов из таблицы выше.
5. Настройте каналы: журнал, чат дежурного, звонок для критичных.
6. Решите, где нужна автоматическая пауза, и проверьте её в тестовой сети.
7. Проведите учение: сымитируйте смену администратора в тестовой сети и замерьте время реакции.
8. Раз в месяц разбирайте ложные срабатывания и корректируйте пороги.

Источники данных

Если мониторинг читает сеть через один внешний сервис, его сбой выключит и мониторинг. Держите второй источник и алерт на то, что сам мониторинг перестал получать блоки. То же правило, что и для мониторинга сайта: следить нужно и за тем, что следит, — см. мониторинг сайта.

Ложные срабатывания

Если дежурный получает десятки предупреждений в день, он перестаёт их читать. Пороги нужно настраивать по фактическим данным: начните с консервативных значений, через две недели посмотрите на распределение сумм и операций и поправьте. Плановые операции, например пополнение горячего кошелька, помечайте заранее.

Связь с веб-частью

Многие атаки начинаются не с контракта, а с интерфейса: подмена скрипта на сайте, утечка ключа API, компрометация админки. Мониторинг контрактов дополняйте мониторингом сайта, утечек и доступов: мониторинг утечек, проверка сайта на взлом.

Дежурство и регламент

Мониторинг без людей — просто журнал. Решите, кто отвечает за алерты в рабочее время, кто ночью и в выходные, и что каждый из них может сделать сам. Дежурный должен иметь доступ к инструкции, контактам подписантов и праву остановить сервис подписи без согласований.

Регламент проверяют учениями. Запустите тестовый критический алерт ночью и посмотрите, через сколько минут кто-то ответит. Если ответа нет — проблема не в правилах мониторинга, а в дежурстве.

Что хранить

Сохраняйте все срабатывания вместе с данными: блок, транзакция, правило, кто и как отреагировал. Этот журнал нужен для разбора инцидентов, настройки порогов и, при необходимости, для обращения к биржам и эмитентам стейблкоинов.

Пример набора правил на старт

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

1. Любая смена владельцев, порога или модулей мультиподписи — критический алерт.
2. Любой выпуск токенов вне расписания — критический алерт.
3. Обновление реализации контракта — критический алерт.
4. Исходящий перевод с горячего кошелька выше суточного среднего в три раза — предупреждение; в пять раз — остановка сервиса подписи.
5. Баланс газа на сервисном адресе ниже недельной нормы — предупреждение.
6. Мониторинг не получал новые блоки дольше нескольких минут — предупреждение.

Мониторинг после обновлений

Каждое обновление контракта или интерфейса меняет нормальное поведение. После релиза первые дни держите пороги строже и смотрите на ошибки транзакций: рост неуспешных вызовов часто первым показывает, что новая версия работает не так, как ожидали. Добавьте в чек-лист релиза пункт «обновить правила мониторинга» — иначе алерты будут молчать о новых функциях или срабатывать на нормальные операции.

Отдельно проверяйте, что мониторинг знает о новых адресах: новый контракт, новый сервисный кошелёк, новая сеть. Адрес, о котором мониторинг не знает, для него не существует.

Что делает студия

Мы настраиваем мониторинг контрактов и кошельков, алерты и автоматическую паузу, а также пишем регламент реакции. Подробно — на странице мониторинг контрактов и кошельков. Что делать, когда алерт сработал, — в статье план реагирования на крипто-инцидент. Оценить, во что обойдётся простой или потеря, поможет калькулятор ущерба от инцидента.