Розробка Telegram-бота для торгівлі на DEX
Користувач відкриває Uniswap V3, бачить вигідний спред між двома пулами — і за час поки він переходить у гаманець, підтверджує транзакцію та платить газ, MEV-бот вже виконав front-run та закрив арбітраж. Telegram-бот з прямим підключенням до RPC та передрахованими маршрутами усуває цей розрив до мінімуму. Але написати такий бот «швидко» — означає наступити на стандартний набір граблей: race conditions на wallet nonce, slip по slippage при резких рухах ціни, утечка приватного ключа через логи.
Архітектура: де реально ломаються DEX-боти
Nonce management при паралельних транзакціях
Найчастіша причина «пропалих» транзакцій — nonce collision. Бот відправляє дві транзакції майже одночасно: обидві читають pending nonce з ноди, обидві отримують одинаковое значення, друга скасовує першу. Якщо нода публічна (Infura, Alchemy free tier) та додає latency — ситуація посилюється.
Рішення: локальний nonce tracker з mutex. Кожне звернення до wallet інкрементує локальний лічильник атомарно, без повторного запиту до ноди. При revert або timeout — синхронізація з eth_getTransactionCount з параметром pending. Це не rocket science, але без цього бот починає зависати при навантаженні.
Slippage та price impact у реальному часі
Uniswap V3 працює з концентрованою ліквідністю — ціна може різко зміститися всередину тіку, якщо ліквідність сконцентрирована у вузькому діапазоні. Фіксований slippageTolerance: 0.5% у боті — це або постійні failed транзакції при volatile ринку, або втрати на price impact при жидкому пулі.
Правильний підхід: симуляція свапу перед відправкою через eth_call до роутера Uniswap V3 Quoter (QuoterV2). Quoter повертає реальний amountOut з урахуванням поточного стану пулу, тіків та fee. Порівнюємо з ціною оракула Chainlink — якщо розходження вище порога, транзакція не відправляється. Це додає один RPC-операцію, але рятує від убиткових виконань.
Private key у змінних окружень — недостатньо
Стандартний совіт «храни ключ в .env» працює до першого взлому сервера або утечки в логи (Node.js вміє логувати environment при необробленому exception). Для торгового бота з реальними коштами мінімум — HSM або AWS KMS для підписи транзакцій. Ключ ніколи не покидає KMS; бот відправляє хеш транзакції на підпис та отримує підписані байти.
Якщо KMS надто дорого — зашифрований keystore з паролем з окремого secret manager, не з змінних середовища. Та обов'язково rate limiting на withdraw-функцію: не більше N ETH на годину з hot wallet.
Стек та реалізація
Основа — Node.js з viem (або ethers.js v6 для проектів, де вже є ethers-інфраструктура). viem переважаний для нових проектів: строга типізація, tree-shakeable, менший bundle size. Для Python-стеку — web3.py з asyncio.
| Компонент | Інструмент | Зачем |
|---|---|---|
| RPC | Alchemy / власна нода | Latency < 100ms, websocket підписки |
| DEX routing | Uniswap V3 SDK / 1inch API | Оптимальний маршрут свапу |
| Price oracle | Chainlink on-chain | Захист від маніпуляцій ціною |
| Мессенджер | Telegram Bot API (grammy/grammY) | Команди, алерти, підтвердження |
| База даних | PostgreSQL / Redis | Історія транзакцій, кеш стану |
| Деплой | Docker + PM2 | Uptime, автоперезапуск |
Telegram-частина намисно тримаємо тонкою: бот приймає команди (/buy, /sell, /balance, /stop), відображає статус транзакції з хешем та лінком на Etherscan. Вся логіка — у окремому trading engine, не у хендлерах Telegram. Це дозволяє тестувати trading engine ізольовано.
Інтеграція з кількома DEX
Якщо потрібна агрегація через кілька DEX (Uniswap, Curve, Balancer), використовуємо 1inch Aggregation API або власну реалізацію routing через The Graph — запитуємо subgraph кожного протоколу для актуальних даних про пулы. Власний routing дає контроль над логікою, але вимагає підтримки при оновленнях протоколів.
Процес розробки
Аналіта та проектування (2-3 дні). Визначаємо стратегію: простий market buy/sell, limit orders через сторонні протоколи (1inch Limit Orders, CoW Protocol), або кастомна логіка. Вибираємо чейн (Ethereum mainnet, Arbitrum, Base — у кожного різний fee та latency). Документуємо модель безпеки гаманця.
Розробка core (3-7 днів). Nonce manager, swap executor, price checker, Telegram handlers. Покриття тестами з mock RPC — симулюємо failed транзакції, nonce collision, network timeout.
Інтеграційне тестування (2-3 дні). Деплой на testnet (Sepolia), тест з реальними RPC-відповідями, перевірка всіх edge cases: wallet з нульовим балансом, газ вище лімітовці, токен з fee-on-transfer.
Деплой та мониторинг. VPS/сервер з uptime monitoring, алерти в Telegram при critical error, логування всіх транзакцій з газом та исполненою ціною.
Орієнтири за строками
Базовий бот для одного DEX з командами buy/sell/balance — 1-1.5 тижні. Мультидекс з агрегацією маршрутів, limit order логікою та розширеним управлінням рисками — 2-3 тижні. Кастомні стратегії (арбітраж, снайпинг листингів) обговорюються окремо — там строки залежать від складності алгоритму та вимог до latency.