Розробка Telegram-бота для мониторингу DeFi-позицій
Позиція в Aave: $80k USDC залог, $50k USDT борг. Health factor 1.21. Ринок падає вночі — через три години health factor перетинає 1.0, позиція ліквідирована, штраф 10%. Користувач прокидається, дивиться у гаманець. Стандартний сценарій, який бот з правильно налаштованими алертами запобігає за 15 хвилин до ліквідації.
Технічні складності, які закапуються у production
Polling vs WebSocket: задержка має значення
Наївна реалізація — cron кожну хвилину опитує RPC. Для health factor це працює, але при волатильності блоки на Ethereum виходять кожні 12 секунд, а ціна оракула Chainlink оновлюється per heartbeat (1 година) або при відхиленні >0.5%. Хвилинний polling пропускає резкі рухи.
Правильний підхід: підписка на події через eth_subscribe("logs") по WebSocket. Aave v3 емітить LiquidationCall(address collateralAsset, address debtAsset, address user, ...). Ловимо це подію — і негайно уведомляємо. Для мониторингу health factor слухаємо ReserveDataUpdated та перераховуємо позицію локально, не чекаючи наступного eth_call.
Проблема з WebSocket: соединение рвається. У production потрібен reconnect з exponential backoff, persistent subscription ID та replay пропущених блоків при відновленні через eth_getLogs з fromBlock: lastProcessedBlock.
Мультичейн: різні адреса, різні ABI
Користувач тримає позиції в Aave v3 на Ethereum, Optimism та Polygon одночасно. Три інстанси з різними PoolAddressesProvider. APY на Polygon може відрізнятися від Ethereum удвічі — це інформація, яку користувач хоче бачити в одному місці.
Архітектура: окремий воркер на кожен чейн, спільна PostgreSQL з таблицею positions(user_address, chain_id, protocol, collateral, debt, health_factor, updated_at). Telegram-бот читає з бази, а не з чейна — це дає швидку відповідь на команди та знижує навантаження на RPC.
Розрахунок APY: пул не стоїть на місці
Compound APY у Aave = (1 + APR/secondsPerYear)^secondsPerYear - 1. APR беруться з getReserveData().currentLiquidityRate (для депозитів) або currentVariableBorrowRate (для борга) — обидва в ray (1e27). Помилка на кожному другому проекті: ділити на 1e18 замість 1e27. Отримують APY у тисячі відсотків, користувачі радіють, поки не побачать реальні цифри.
Що будуємо
Стек
| Шар | Технологія |
|---|---|
| Чейн-мониторинг | viem (WebSocket transport), ethers.js fallback |
| Протоколи | Aave v3 Pool ABI, Compound v3 Comet ABI |
| Оракули | Chainlink Price Feed (прямі вызови + The Graph) |
| База даних | PostgreSQL — позиції, алерти, історія |
| Черга | BullMQ (Redis) — обробка уведомлень без пиків |
| Бот | grammY (TypeScript) або python-telegram-bot |
| Деплой | Docker + PM2, VPS з аптаймом 99.9% |
Алерт-логіка
Конфігурумні пороги на користувача: health factor < 1.3, < 1.1 (критично), зміна APY >20% за 24 години, поява нової ліквідації по адресі. Дедупліація через Redis з TTL: одне уведомлення на подію, повтор через 30 хвилин якщо ситуація не змінилася.
Для health factor: не просто поточне значення, а тренд — бот показує "знизився на 0.15 за останні 6 годин". Це actionable інформація.
Команди бота
/positions — всі відкриті позиції з health factor та поточним APY. /alerts — управління порогами. /history [address] — історія змін health factor за 7 днів, у вигляді текстового sparkline. /liquidations — останні ліквідації по стежуваних адресах.
Мультиаккаунт: один Telegram-користувач може мониторити кілька адрес (власні + командні гаманці).
Процес роботи
Аналітика (1-2 дні). Список протоколів, чейнів, типів позицій. Визначаємо, потрібен ли мониторинг LP-позицій Uniswap v3 (impermanent loss, out-of-range алерти) — це окремий модуль.
Розробка (3-5 днів). Chain listener + position calculator + Telegram bot + PostgreSQL schema. Юнит-тести на розрахунок APY та health factor з моками RPC.
Деплой та мониторинг. Docker Compose, логи у Loki, метрики у Grafana. SLA на алерт: <30 секунд від события у чейні до Telegram-повідомлення.
Орієнтири за строками
Базовий бот для Aave v3 на одному чейні з health factor алертами — 3-4 дні. Мультичейн з підтримкою Aave + Compound + мониторингом LP-позицій — 1.5-2 тижні. Інтеграція з власним протоколом через кастомний ABI додає 2-3 дні.
Вартість рассчитується після аналізу вимог.