Розробка системи On-chain алертів під ключ

On-chain моніторинг у реальному часі — завдання, яке здається простим, доки ви не стикаєтеся з обривами WebSocket, дублюванням логів та спамом сповіщень. Багато розробників витрачають години на налагодження пайплайнів, а критична подія може бути пропущена через неправильну обробку реконнекту. Ми створюємо системи алертів під ключ, які вирішують ці проблеми на рівні архітектури: черги з Redis Streams, дедуплікація по (txHash, logIndex), механізми доставки з гарантією SLA 99.9%. Досвід — понад 5 років у Web3, десятки впроваджених рішень для DeFi протоколів, NFT маркетплейсів та аналітичних платформ. Ми реалізували понад 50 проектів — кожен з індивідуальною конфігурацією правил. Готові оцінити ваш проект і запропонувати оптимальну конфігурацію, яка заощадить ваш час та ресурси. Пишіть нам — отримайте безкоштовний аудит вашої системи моніторингу.

Типи відстежуваних подій

• Contract events (logs) — найпоширеніше: Transfer, Swap, Deposit, Liquidation, Mint. Декодуються через ABI з raw topics + data.
• Large transactions — трансфери вище порогового значення в USD. Вимагають конвертації через price feed (Chainlink, CoinGecko API) на момент події.
• Address activity — будь-яка транзакція з/на відстежуваний адрес (whale watching, portfolio tracking).
• MEV events — sandwich attacks, arbitrage, flashloans. Детектуються через аналіз патернів у рамках одного блоку.
• Protocol health — health factor на Aave/Compound нижче порогу, utilization rate вище 90%, падіння TVL більше X%.
• NFT події — mint, sale, transfer конкретних колекцій.

Архітектура системи

Ingestion layer

Два варіанти отримання подій:

WebSocket subscriptions — мінімальна latency (< 1 сек від блоку). Проблема: при реконнекті пропускаються блоки. Для обробки використовується catch-up механізм: при старті обробляються пропущені блоки, потім підписка на нові через watchBlockNumber.

Polling — кожні N секунд робимо eth_getLogs за останні блоки. Менш ефективно, але більш надійно. Для систем з SLA — комбінація: WS для швидкості, polling як fallback.

Event processing pipeline

[WS / Polling] → [Raw Event Queue] → [Decoder] → [Enricher] → [Rule Engine] → [Alert Queue] → [Delivery] 

Decoder — ABI-декодинг raw logs. Для невідомих контрактів — спроба знайти ABI через Etherscan API або 4byte.directory.

Enricher — збагачення даних: USD-вартість через price feed, labels (біржа? whale? відомий протокол?), entity resolution (кілька адрес одного суб'єкта).

Rule Engine — перевірка умов алертів проти збагаченої події.

Rule Engine

Гнучка система правил — ключовий компонент. Правила конфігуруються без деплою коду:

{ "name": "Large ETH Transfer", "chains": ["ethereum"], "event_signatures": ["0xddf252ad..."], "conditions": [ { "field": "value_usd", "operator": "gt", "value": 1000000 }, { "field": "token_symbol", "operator": "eq", "value": "ETH" } ], "condition_logic": "AND", "channels": ["telegram_main", "webhook_trading_desk"], "cooldown_seconds": 60 } 

Як працює система on-chain алертів

1. Інгестія: події отримуються через WebSocket або polling.
2. Декодування: raw logs перетворюються на зрозумілі структури.
3. Збагачення: додаються ціна, мітки, сутності.
4. Перевірка правил: кожна подія зіставляється з налаштованими умовами.
5. Дедуплікація: виключаються дублікати (по txHash + logIndex).
6. Доставка: сповіщення надсилається в задані канали.

Чому дедуплікація критична?

При кількох нодах або при catch-up одна подія може прийти кілька разів. Дедуплікація по (transaction_hash, log_index) в Redis:

async function processEvent(event: DecodedEvent): Promise<boolean> { const key = `processed:${event.txHash}:${event.logIndex}`; const isNew = await redis.set(key, '1', 'EX', 86400, 'NX'); return isNew !== null; } 

Згідно з документацією Redis, команда SET з опцією NX гарантує атомарну перевірку. Це запобігає повторній обробці навіть при паралельних воркерах.

Як забезпечити надійну доставку?

Telegram — найбільш популярний для крипто-алертів. Доставка реалізується через Bot API з форматуванням MarkdownV2 та урахуванням rate limit (30 повідомлень/сек на бота, 1 повідомлення/сек в один чат). При високочастотних подіях потрібна батчизація або агрегація.

Webhook — HTTP POST на довільний endpoint з retry та exponential backoff. Email — для важливих подій з низькою частотою через SendGrid/AWS SES.

Discord — через webhook або Bot API. PagerDuty — для критичних подій, що вимагають негайної реакції.

Анти-spam та агрегація

Проблема: при flash crash або великій події генеруються сотні алертів за хвилину. Рішення:

• Cooldown per rule — не слати повторний алерт по тому ж правилу N секунд.
• Digest mode — агрегувати події за 5/60 хвилин і відправляти зведення.
• Threshold batching — «відбулося 47 ліквідацій на Aave за останні 10 хвилин, загальна сума $2.3M».

Склад deliverables

• Архітектурна документація та схема пайплайну.
• Вихідний код з коментарями, конфіги для розгортання.
• Rule Engine з набором попередньо встановлених правил під ваш кейс.
• Доступ до Telegram-бота, webhook-ендпоінтів.
• Моніторинг системи (Prometheus + Grafana), дашборди.
• Навчання команди, документація по додаванню правил.
• Гарантійна підтримка 1 місяць після здачі.

Моніторинг системи

Система алертів повинна моніторити себе:

• Block lag — відставання від head chain. Алерт якщо > 10 блоків.
• Processing queue depth — зростання черги = вузьке місце.
• Delivery failures — невдалі спроби відправки в кожен канал.
• Rule match rate — аномальне зростання = можливо правило занадто широке.

# Prometheus метрики alert_system_block_lag_gauge alert_system_queue_depth_gauge alert_system_delivery_total{channel, status} alert_system_rule_matches_total{rule_id} 

Стек та орієнтовні строки

Базова система (5–10 типів подій, Telegram + webhook, одна мережа): 2–3 тижні. Мультичейн, складні складені правила, кастомний UI для керування алертами — 4–6 тижнів.

Пропущена подія може коштувати тисячі доларів, якщо це ліквідація позиції або шахрайська транзакція. Інвестиції в якісний алерт-моніторинг окупаються за рахунок запобігання втратам. Наша система на основі WebSocket + caching обробляє події в 10 разів швидше, ніж polling-only рішення, при тій же надійності. Пропускна здатність — до 10 000 подій на секунду, latency менше 500 мс, дедуплікація знижує кількість алертів на 30-50%. Вартість впровадження починається від $5 000 для базової конфігурації, а економія від завчасно виявлених інцидентів може складати $50 000+ на рік.

Зв'яжіться з нами, щоб отримати оцінку вашого проекту та комерційну пропозицію. Замовте консультацію з архітектури on-chain моніторингу — ми допоможемо обрати оптимальне рішення та обговоримо деталі впровадження. Вам входить: повний аудит, налаштування правил, інтеграція з вашими каналами та навчання команди. Пишіть прямо зараз — перша консультація безкоштовна.