Разработка 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 | Упtime, автоперезапуск |
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). Документируем wallet security модель.
Разработка 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.