Моніторинг DeFi-позицій: де ламається облік
Застиглий реєстр показує позицію здоровою, а в протоколі коефіцієнт застави вже пройшов поріг.
Причина — розсинхронізація даних: індексатор відстав на кілька блоків, частина подій за позикою залишилася нерозібраною, а ціна береться з одного джерела і не перераховується на різкому русі ринку.
Стан застави в інтерфейсі та в контракті розходиться, і саму розбіжність ніхто не вимірює — вона випливає лише при спробі закрити позицію.
Ціна помилки — не незручний звіт, а пропущений ризик ліквідації.
Поки облік застави живе в таблиці, що оновлюється за розкладом, вікно між зростанням ризику та реакцією обчислюється годинами: за цей час позицію закривають примусово за невигідною ціною, а потім дні йдуть на ручний розбір транзакцій.
На кількох протоколах ситуація гірша — у кожного свої формати подій, свої правила перерахунку накопичених відсотків і свої пороги, звести їх в один звід без звірки неможливо.
Тому моніторинг DeFi-позицій будують навколо звірки, а не навколо одного джерела даних. Стан застави перераховують із сирих подій, незалежно перечитують із блокчейну та розбіжність виносять окремим сигналом із зазначенням, який саме параметр пішов і наскільки.
Тоді повідомлення приходить на порозі, а не коли спрацював зовнішній ліквідатор, і в команди залишається час на часткове погашення або додавання забезпечення.
Як це закривається на практиці — від схеми збору подій до політики порогів і порядку ручних дій при спрацюванні — розбираємо нижче.
Що дає безперервний контроль застави та дохідності
Застава за позицією живе своїм життям: ціна базового активу рухається, ставки запозичення змінюються, частина забезпечення йде в стейкінг із плаваючою дохідністю.
Безперервне опитування стану — за розкладом і за подіями на кшталт різкого руху ціни чи великої угоди за адресою — тримає актуальний запас до ліквідації, а раннє попередження приходить на підході до порогу, а не після спрацювання.
Розрахунок дохідності збирається з нарахованих відсотків, вартості активів у базовій валюті та комісій, які позиція сплачує або отримує.
Ми зводимо це в метрику за кожною позицією та за портфелем загалом: видно, скільки приносить кожен рахунок і де результат з'їдається вартістю позичених коштів. Дані лягають у сховище з історією — будь-яку розбіжність можна розібрати покроково, а не з пам'яті.
Єдиний реєстр рахунків прибирає розрізнені гаманці, мережі та таблиці: адреси, ринки, типи позицій і правила оповіщення лежать в одному довіднику з версіонуванням.
Збір стану йде з контракту Aave, пороги порівняння задаєте ви, а повідомлення приходить у узгоджений канал людиночитним текстом: що сталося, наскільки запас нижчий за поріг, яку позицію зачепило.
З погляду результату час реакції на подію вимірюється хвилинами замість годин, частка впійманих ризиків зростає, а клас відмов «дізналися після факту» зникає разом із ручними перевірками.
Зниження ризику ліквідації тут не обіцянка, а наслідок: пороги перераховуються автоматично, правила спрацьовують без участі людини.
Порівняння підходів до збору даних із протоколів
Точність повідомлення визначається не логікою правил, а тим, як ми отримуємо стан протоколу. Помилка у зборі даних із протоколів проявляється пізніше й дорожче: сигнал приходить після того, як позиція пішла в ліквідацію, або дублюється на кожному обриві з'єднання. Нижче — робочі схеми з умовами застосовності та обмеженнями методів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Періодичне опитування мережі | позиції змінюються повільно: застави, ставки, пули з низькою активністю; потрібен повний зріз стану | затримка дорівнює кроку опитування; навантаження зростає лінійно з кількістю адрес і частотою |
| Підписка на події | потрібна реакція в межах кількох блоків: ліквідації, різкий зсув курсу в пулі | потрібен власний індексувальний шар і розбір реорганізацій; при розриві з'єднання частина подій губиться, потрібна звірка з історією |
| Гібридна схема | основний режим для роботи з реальними позиціями: підписка на термінові тригери, опитування як підтверджувальний контур | два джерела потрібно зводити між собою, розв'язувати розбіжності та придушувати дублі |
| Зовнішні сервіси даних | швидкий старт і покриття багатьох мереж без власної інфраструктури | залежність від чужого індексу та його лімітів, немає доступу до сирих логів, затримка й повнота поза нашим контролем |
Вибір перевіряємо на історичних даних: проганяємо знімки та події за минулий період, рахуємо частку розбіжностей і кількість пропущених тригерів за кожним типом позицій.
Якщо періодичне опитування мережі дає пропуски на волатильних пулах, підтверджувальний контур переводимо на підписку. Результат фіксується у звіті за етапом разом із картою джерел за кожним протоколом.
Як відбувається впровадження системи: етапи робіт
Впровадження ведемо короткими ітераціями, і перший крок — не розробка, а аудит джерел даних: де розміщені кошти, які контракти їх обслуговують і з якою затримкою надходять курси. Поки перелік джерел та їхні обмеження не зафіксовані, розрахунок позиції розходиться з реальністю.
- Аудит джерел даних. Інвентаризуємо позиції за протоколами й мережами та фіксуємо, що віддає кожне джерело: частина даних читається з контрактів, частина — з подій, курси беремо з оракульних каналів Chainlink.
- Схема обліку та зберігання. Визначаємо, як нормалізуються дані різних протоколів і як рахується вартість позиції з урахуванням позик, застав і нарахованих відсотків; історію зберігаємо, щоб розрахунок можна було переперевірити.
- Налаштування порогів. Правила спрацювання: відхилення ціни, наближення до ліквідації, падіння дохідності, простій джерела. Пороги задаємо з гістерезисом і рівнями терміновості, щоб канал не перетворювався на потік шуму.
- Перевірка на історичних даних. Проганяємо правила на архіві: скільки оповіщень пішло б за минулий період, яка частка хибних, чи встигало оповіщення до критичної події. За результатом калібруємо пороги.
- Доставка та доступи. Підключаємо канали оповіщення та розмежовуємо права: критичне йде черговому одразу, інформаційне — до загального зведення.
- Передача системи. Віддаємо конфігурації, схему потоків даних, регламент чергування та інструкцію з додавання нових протоколів, навчаємо команду замовника.
- Розбір перших спрацювань. Перші тижні супроводжуємо роботу й розбираємо кожне оповіщення: що спрацювало правильно, що потребує налаштування, які джерела варто додати.
Що передаємо на руки: конфігурації, схеми, регламенти
Передаємо не архів із вихідними кодами, а робочий контур з описом того, як він влаштований і що робити, коли він мовчить.
Кожен артефакт прив'язаний до конкретної дії: зі схеми зрозуміло, де шукати розсинхрон, з регламенту — за скільки хвилин піднімається черговий, з політики — хто має право змінювати пороги.
- Схеми потоків даних: шлях від джерел цін і стану протоколів до розрахунку коефіцієнта здоров'я позиції, з точками відмови та поведінкою при розбіжності курсів між джерелами.
- Карта інтеграцій: перелік зовнішніх вузлів, агрегаторів цін і каналів доставки, частота опитування, ліміти звернень і порядок перемикання на резервне джерело.
- Конфігурації правил моніторингу: пороги коефіцієнта здоров'я та частки позичених коштів, вікна тиші, дедуплікація повторів, драбина ескалації — файлами в репозиторії, версіонуються разом із кодом.
- Регламент повідомлень: кому й куди йде сигнал, через скільки секунд після події, що вважається критичним, як придушуються хибні спрацювання на різких рухах ринку.
- Політики доступу: ролі та права на зміну порогів, ротація ключів до вузлів і каналів, журнал дій операторів, порядок дій при компрометації токена доступу.
- Документація системи: архітектура розрахунку, словник метрик, чек-ліст розгортання та порядок відновлення зі снапшотів стану позицій.
- Регламент чергування: графік ротації, нормативний час реакції, точки ескалації та обов'язковий прогін на стенді перед викочуванням змін в інтеграції.
Розбір польотів за кожним пунктом проводимо на передачі — із записом і розбором двох навчальних спрацювань.
Кейс: контроль DeFi-позицій замість ручних таблиць
Замовник керує ліквідністю в кількох пулах кредитування. Позиції відстежувалися вручну: черговий раз на кілька годин звіряв заставу, позику та поточну ціну, тому до ліквідації підходили вже постфактум — коли захищати позицію не було чим.
Що було до впровадження
Середній час виявлення ризику — близько чотирьох годин, у вихідні розтягувався до дванадцяти. Перевірки були неповними: частина позицій випадала з таблиці при зміні чергового, а поріг оповіщення кожен налаштовував по-своєму.
Розбір інциденту займав майже день — з листування та скриншотів відновлювали, хто що бачив і в який момент.
Що змінили і що стало
Зібрали сервіс, який читає стан позицій із публічних джерел і звіряє з ціновими орієнтирами з DefiLlama. Правила оповіщень описали декларативно: поріг забезпечення позиції, швидкість зміни ціни, окремі умови для нічних змін.
Повідомлення приходить у черговий канал із посиланням на позицію та історією її змін, тому інженер бачить контекст, а не абстрактне «спрацювало».
- виявлення ризику: з чотирьох годин до двох хвилин;
- частка хибних спрацювань: 40% → 6% — залишилися тільки реальні коливання ціни;
- розбір інциденту: день → 20 хвилин, уся хронологія вже в журналі;
- пропущені ризики за квартал: три → нуль.
Історію змін і спрацювань тепер зберігає сервіс, а не людина: таблиці перестали бути єдиним джерелом правди про стан позицій.
Що робити, якщо дані за рахунками розходяться з ланцюгом
Розбіжність даних між обліковою базою та ланцюгом майже ніколи не означає, що «зламалася мережа». У більшості випадків губиться ділянка обробки: перезапуск індексатора, змінена логіка контракту, відкат підтвердженої гілки. Тому перший крок — не правити цифри в базі, а знайти точку, де розбіжність виникла.
Далі принцип один: джерело істини — ланцюг, а локальні записи відновлювані. Перескладання історії дає детермінований результат лише за незмінного набору правил розбору, тому спочатку звіряємо логіку контрактів із тим, що виконується зараз, і лише потім запускаємо прохід заново.
| Причина розбіжності | Як проявляється | План відновлення |
|---|---|---|
| Пропуск ділянки після перезапуску | Позиція «завмирає», хоча в ланцюгу рухи були | Перескладання історії за діапазоном, потім повторна звірка |
| Змінена логіка контракту | Частина подій не розпізнається, суми сходяться не повністю | Звірка логіки контрактів, оновлення правил розбору |
| Відкат підтвердженої гілки | Записи заднім числом стають невірними | Відкат зачеплених записів, повторна звірка |
| Різний порядок обробки джерел | Алерти приходять не за тими позиціями | Єдиний порядок обробки, повторна звірка на історичних даних |
План відновлення закривається повторною звіркою на історичному вікні, а не на останньому блоці — так видно, що розбіжність пішла цілком, а не замаскована. Після цього розбіжність даних виносять окремим алертом: наступний розрив ловиться в момент появи, а не через тиждень.
Політики доступу, ліміти та канали повідомлень
Політики доступу будуємо навколо ролей сервісів: вузол читання блокчейну, індексатор, рушій розрахунку позицій і відправник повідомлень отримують окремі облікові дані з мінімально потрібними правами.
Розрахунковий контур не має права надсилати сигнали напряму, а відправник не бачить ключів — компрометація одного сервісу не відкриває решту. Кожна дія лягає в журнал подій, доступний лише на долисування: хто, що і коли запросив.
Ліміти повідомлень захищають від потоку однотипних сигналів. Дедуплікація йде за ключем «протокол + позиція + тип події», і у вікні агрегації повтори згортаються в одне повідомлення з лічильником.
Поріг спрацювання задаємо часткою від розміру позиції, а не абсолютним числом, — шум від дрібних коливань не доходить до каналу. Канали оповіщення розведені за критичністю: миттєві для ризику ліквідації, дайджест за розкладом для решти.
Що відбувається, якщо джерело даних недоступне?
Сервіс публікує сигнал живості та позначає розрахунок як застарілий — позиція не закривається за останнім відомим значенням. У канал іде окреме повідомлення про недоступність джерела, повтори виконуються з наростаючим інтервалом до відновлення.
Чи можна надати сервісу доступ лише на читання?
Так. Ролі сервісів розмежовані, облікові дані обмежені своєю ділянкою роботи, а журнал подій показує, хто і коли звертався до даних. Відкликання доступу для одного сервісу не зачіпає інші контури.
Обговоримо ваше завдання і повернемося з планом робіт
Щоб повернутися з планом робіт, а не із загальними словами, нам потрібен від вас мінімум: перелік мереж і протоколів, де відкриті позиції, набір подій, за якими потрібен сигнал — зміна здоров'я позики, вихід ціни за коридор, наближення до ліквідації, збій у джерелі даних, — і канали доставки оповіщень: пошта, месенджер, виклик вашого сервісу.
Зі свого боку фіксуємо етапи до першого рядка конфігурації: склад постачання, межі відповідальності та точки, де потрібне ваше підтвердження.
- Розбір завдання: розмічаємо, які позиції та метрики потрапляють у моніторинг, а які свідомо залишаємо за периметром.
- Схема збору даних: джерела, частота опитування та поведінка при недоступності вузла чи провайдера.
- Правила спрацювання: пороги, вікна усереднення, придушення дублів, пріоритети сигналів.
- Канали доставки: маршрутизація за критичністю, ескалація черговому, журнал доставлених і відхилених оповіщень.
- Оцінка термінів: план за етапами з контрольними точками, де ви бачите працюючий результат, а не звіт про роботи.
- Склад постачання та супровід після впровадження: конфігурації, схема розгортання, інструкції для чергової зміни, реакція на зміну контрактів протоколів і налаштування порогів за фактом хибних спрацювань.
Опишіть завдання у вільній формі — повернемося з оцінкою термінів і планом робіт за етапами.
