Разработка системы мониторинга DeFi-позиций с алертами

Мониторинг DeFi-позиций: где ломается учёт

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

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

Поэтому мониторинг DeFi-позиций строят вокруг сверки, а не вокруг одного источника данных. Состояние залога пересчитывают из сырых событий, независимо перечитывают из блокчейна и расхождение выносят отдельным сигналом с указанием, какой именно параметр ушёл и насколько. Тогда уведомление приходит на пороге, а не когда сработал внешний ликвидатор, и у команды остаётся время на частичное погашение или добавление обеспечения.

Как это закрывается на практике — от схемы сбора событий до политики порогов и порядка ручных действий при срабатывании — разбираем ниже.

Что даёт непрерывный контроль залога и доходности

Залог по позиции живёт своей жизнью: цена базового актива двигается, ставки заимствования меняются, часть обеспечения уходит в стейкинг с плавающей доходностью. Непрерывный опрос состояния — по расписанию и по событиям вроде резкого движения цены или крупной сделки по адресу — держит актуальный запас до ликвидации, а раннее предупреждение приходит на подходе к порогу, а не после срабатывания.

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

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

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

Сравнение подходов к сбору данных из протоколов

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

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

Как проходит внедрение системы: этапы работ

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

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

Что передаём на руки: конфигурации, схемы, регламенты

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

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

Разбор полётов по каждому пункту проводим на передаче — с записью и разбором двух учебных срабатываний.

Кейс: контроль DeFi-позиций вместо ручных таблиц

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

Что было до внедрения

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

Что изменили и что стало

Собрали сервис, который читает состояние позиций из публичных источников и сверяет с ценовыми ориентирами из DefiLlama. Правила оповещений описали декларативно: порог обеспечения позиции, скорость изменения цены, отдельные условия для ночных смен. Уведомление приходит в дежурный канал со ссылкой на позицию и историей её изменений, поэтому инженер видит контекст, а не абстрактное «сработало».

• обнаружение риска: с четырёх часов до двух минут;
• доля ложных срабатываний: 40% → 6% — остались только реальные колебания цены;
• разбор инцидента: день → 20 минут, вся хронология уже в журнале;
• пропущенные риски за квартал: три → ноль.

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

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

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

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

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

Политики доступа, лимиты и каналы уведомлений

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

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

Можно ли выдать сервису доступ только на чтение?

Да. Роли сервисов разграничены, учётные данные ограничены своим участком работы, а журнал событий показывает, кто и когда обращался к данным. Отзыв доступа для одного сервиса не затрагивает остальные контуры.

Обсудим вашу задачу и вернёмся с планом работ

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

Со своей стороны фиксируем этапы до первой строки конфигурации: состав поставки, границы ответственности и точки, где нужно ваше подтверждение.

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

Опишите задачу в свободной форме — вернёмся с оценкой сроков и планом работ по этапам.