Розроблення системи мониторингу DeFi-позицій
Health factor 1.05 в Aave — це 5% до ліквідації. При високій волатильності ринку від 1.05 до ліквідації може пройти кілька хвилин. Користувач без системи мониторингу дізнається про проблему після: позиція ліквідирована, liquidation bonus (8-15%) пішов ліквідатору. На великих позиціях це тисячі доларів, які можна було б зберегти, додавши collateral вчасно.
Що та як мониторити: технічні деталі
Health factor: формула та пороги для алертів
У Aave v3 health factor розраховується як:
HF = (sum(collateral_i * liquidationThreshold_i * price_i)) / (sum(debt_j * price_j))
Через смарт-контракт: IPool.getUserAccountData(address) повертає healthFactor у форматі 1e18 = 1.0. Значення нижче 1e18 — позиція ліквідируєма.
Пороги для алертів:
- HF < 1.5 — попередження: додайте collateral
- HF < 1.2 — критично: негайне дія
- HF < 1.05 — екстренно: ліквідація неминуча
Polling через multicall (MakeDao Multicall3 на 0xcA11bde05977b3631167028862bE2a173976CA11) — за один RPC виклик запитуємо HF для всіх відслідковуваних адрес. Для 100 адрес — один eth_call замість 100. Інтервал polling: кожні 30 секунд у нормальному режимі, кожні 5 секунд при HF < 1.3.
Compound v3 та Euler: відмінності механіки
У Compound v3 немає єдиного health factor — є isLiquidatable(address) bool метод та окремо borrowBalanceOf + collateralBalanceOf. Для розуміння близькості до ліквідації: borrowBalance / (collateralBalance * collateralFactor * price).
Euler (до паузи у 2023 році) мав subaccount систему — один адрес = 256 незалежних субсчётів. Система мониторингу повинна перебирати субсчёти через eulerAccount = address(uint160(mainAddress) ^ subAccountId). Це неочевидно та багато систем мониторингу Euler ігнорували субсчёти.
LP-позиції Uniswap v3: fee накопління та out-of-range
Для LP-мониторингу потрібні три метрики: поточна USD вартість позиції, накопленні fees, статус in/out-of-range.
Поточна вартість через NonfungiblePositionManager.positions(tokenId) + розрахунок amount0/amount1 по поточному tick пулу. Можна робити через статик-колл до view функції або через The Graph subgraph (запит кожні 5 хвилин).
Fees — періодично через NonfungiblePositionManager.collect з amount0Max = type(uint128).max у режимі симуляції (eth_call, не транзакція). Або через розрахунок feeGrowthInside як описано у Uniswap v3 whitepaper.
Out-of-range: підписка на Swap» события пулу, порівняння currentTickзtickLower/tickUpper` позиції.
Архітектура системи
Компоненти
Indexer — сервіс, який читає on-chain дані та зберігає у базу даних. Два режими: polling (кожні N секунд через multicall) та event-driven (WebSocket subscriptions). Для мониторингу HF — polling. Для LP out-of-range событій — event-driven.
Alert engine — применяет правила до поточних даних. Підтримує кастомні пороги: кожен користувач налаштовує свої HF thresholds, мінімальні fees для сповіщення, preferred notification channels.
Notification dispatcher — відправляет уведомлення. Канали: Telegram Bot (найпопулярніший у DeFi), Email через SendGrid/Resend, Webhook для кастомних інтеграцій, Push notifications через Web Push API.
API/Frontend — dashboard для користувачів: поточні позиції, історія змін HF, історія ліквідацій, APY за період.
Зберігання даних
PostgreSQL для time-series даних про позиції. Схема:
CREATE TABLE position_snapshots (
id BIGSERIAL PRIMARY KEY,
address VARCHAR(42) NOT NULL,
protocol VARCHAR(20) NOT NULL, -- 'aave_v3', 'compound_v3', 'uniswap_v3'
chain_id INTEGER NOT NULL,
health_factor NUMERIC,
collateral_usd NUMERIC,
debt_usd NUMERIC,
snapshot_at TIMESTAMPTZ NOT NULL
);
CREATE INDEX ON position_snapshots (address, protocol, snapshot_at DESC);
Для часових рядів з високою частотою запису — TimescaleDB extension для PostgreSQL з automatic partitioning за часом.
The Graph subgraph для Uniswap v3 позицій знижує навантаження на RPC: замість виклику positions() для кожного tokenId — один GraphQL запит по owner address. Але The Graph має затримку ~1-5 хвилин, тому для real-time мониторингу out-of-range — WebSocket subscriptions.
Мультичейн та газ-алерти
Сучасні користувачі DeFi працюють на Ethereum, Arbitrum, Optimism, Polygon одночасно. Система повинна агрегувати позиції зі всіх чейнів у єдиному dashboard. Для кожного чейну — окреме WebSocket підключення до ноди.
Додатково корисно: мониторинг gas price (Ethereum base fee через eth_gasPrice) + сповіщення «зараз дешево, хороший час для rebalancing». Ethereum base fee нижче 10 gwei у нерабочий час — rare event, але користувачі цінують такі сповіщення.
Стек розроблення
Backend: Node.js (TypeScript) + viem для on-chain взаємодій. Redis для черги алертів та дедупліцирування. PostgreSQL + TimescaleDB для зберігання. Bull.js для job scheduling (polling jobs).
Frontend: React + wagmi для wallet connection (користувач логінується через гаманець, не email/password). TanStack Query для data fetching. Recharts або TradingView Lightweight Charts для HF timeline.
Процес роботи
Проектування (2-3 дні). Список протоколів, чейнів, метрик. Схема бази даних.
Розроблення indexer + alert engine (1 тиждень). Multicall polling, WebSocket subscriptions, alert rules.
Notification dispatcher (2-3 дні). Telegram bot, email, webhook.
Frontend dashboard (3-5 днів). Positions overview, HF timeline, alert configuration.
Деплой. VPS + managed PostgreSQL. Мониторинг самого сервісу через Uptime Robot.
Орієнтири за часом
Базова система (Aave + Compound, Telegram alerts): 1 тиждень. Мультичейн система з LP мониторингом, dashboard та кастомними правилами: 2-3 тижні.