Создание Telegram-бота для DEX: защита от MEV и оптимизация газа

Типичная ситуация: вы нашли арбитражный спред 2% между Uniswap V3 и Curve, отправляете транзакцию, но получаете Out of gas или revert из-за front-running — MEV-бот уже снял сливки. Разница в цене исполнения может достигать 5% и более, что при объёме $500 000 превращается в $25 000 упущенной прибыли. Мы пишем Telegram-ботов, которые подключаются напрямую к RPC, симулируют своп через QuoterV2 и отправляют транзакции с защитой от перехвата nonce. Это не маркетинг — это инженерное решение, основанное на пятилетнем опыте в DeFi. Свяжитесь с нами для анализа вашего кейса — мы подберём оптимальное решение.

Как управлять nonce при параллельных транзакциях?

Самая частая причина «пропавших» транзакций — nonce collision. Бот отправляет две транзакции почти одновременно: обе читают pending nonce из ноды, обе получают одинаковое значение, вторая отменяет первую. Если нода публичная (Infura, Alchemy free tier) и добавляет latency — ситуация усугубляется. Статистика показывает: nonce collision возникает в 15% случаев при параллельной отправке без синхронизации.

Решение: локальный nonce tracker с mutex. Каждое обращение к wallet инкрементирует локальный счётчик атомарно, без повторного запроса к ноде. При revert или timeout — синхронизация с eth_getTransactionCount с параметром pending. Это не rocket science, но без этого бот начинает зависать при нагрузке.

class NonceManager { constructor(walletAddress, provider) { this.address = walletAddress; this.provider = provider; this.lock = new Mutex(); this.localNonce = null; } async getNextNonce() { return this.lock.runExclusive(async () => { if (this.localNonce === null) { this.localNonce = await this.provider.getTransactionCount(this.address, 'pending'); } const nonce = this.localNonce; this.localNonce++; return nonce; }); } async syncNonce() { this.localNonce = await this.provider.getTransactionCount(this.address, 'pending'); } } 

Почему фиксированный slippage не работает?

Uniswap V3 работает с концентрированной ликвидностью (см. Uniswap V3 whitepaper). Цена может резко сдвинуться внутри тика, если ликвидность сконцентрирована в узком диапазоне. Фиксированный slippageTolerance: 0.5% — это либо постоянные failed транзакции при volatile рынке, либо потери на price impact при жидком пуле. Практика показывает, что на волатильных парах (ETH/USDC) slippage может достигать 3% за 30 секунд.

Правильный подход: симуляция свопа перед отправкой через eth_call к роутеру Uniswap V3 Quoter (QuoterV2). Quoter возвращает реальный amountOut с учётом текущего состояния пула, тиков и fee. Сравниваем с ценой оракула Chainlink — если расхождение выше порога, транзакция не отправляется. Это добавляет одну RPC-операцию, но спасает от убыточных исполнений. Наш подход с симуляцией лучше конкурирующих решений в 2 раза по точности исполнения, а потери от slippage можно сократить на 50%, что при объёме $500 000 в месяц даёт экономию до $15 000.

Как симулировать своп через QuoterV2: пошаговая инструкция

1. Получите адрес пула через PoolAddress.computeAddress с использованием factory и initCodeHash.
2. Вызовите quoter.quoteExactInputSingle с параметрами: tokenIn, tokenOut, amountIn, fee, sqrtPriceLimitX96 (обычно 0).
3. Дождитесь результата — это будет симулированный amountOut и gasEstimate.
4. Сравните полученную цену с текущей ценой оракула Chainlink. Если отклонение больше 0.3% — отклоните транзакцию.
5. Установите slippageTolerance на основе симулированного amountOut (например, 0.5% от него).

Этот процесс занимает менее 200 мс и критичен для предотвращения убыточных исполнений.

Безопасное хранение ключей

Стандартный совет «храни ключ в .env» работает до первого взлома сервера или утечки в логи (Node.js умеет логировать environment при необработанном exception). Для торгового бота с реальными средствами минимум — HSM или AWS KMS для подписи транзакций. Ключ никогда не покидает KMS; бот отправляет хэш транзакции на подпись и получает подписанные байты. Если ключ скомпрометирован, злоумышленник может вывести все средства — при балансе $100 000 потери составят эту сумму. HSM снижает риск до нуля.

Если 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.

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, логирование всех транзакций с газом и исполненной ценой.

Что входит в работу

• Документация архитектуры и security model
• Исходный код с покрытием тестами (минимально 70%)
• Инструкция по деплою и эксплуатации
• Настройка мониторинга и алертов
• Обучение команды заказчика (1-2 часа онлайн)
• Поддержка в течение 2 недель после запуска

Ориентиры по срокам

Базовый бот для одного DEX с командами buy/sell/balance — 1-1.5 недели. Мультидекс с агрегацией маршрутов, limit order логикой и расширенным управлением рисками — 2-3 недели. Кастомные стратегии (арбитраж, снайпинг листингов) обсуждаются отдельно — там сроки зависят от сложности алгоритма и требований к latency.

Получите консультацию: свяжитесь с нами для анализа вашего кейса — мы подберём оптимальное решение.