Типичная ситуация: вы нашли арбитражный спред 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, но без этого бот начинает зависать при нагрузке.
Пример nonce manager на JavaScript
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: пошаговая инструкция
- Получите адрес пула через
PoolAddress.computeAddressс использованиемfactoryиinitCodeHash. - Вызовите
quoter.quoteExactInputSingleс параметрами:tokenIn,tokenOut,amountIn,fee,sqrtPriceLimitX96(обычно 0). - Дождитесь результата — это будет симулированный
amountOutиgasEstimate. - Сравните полученную цену с текущей ценой оракула Chainlink. Если отклонение больше 0.3% — отклоните транзакцию.
- Установите
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.
| Метод | Безопасность | Скорость | Стоимость |
|---|---|---|---|
| .env | Низкая | Высокая | Бесплатно |
| Зашифрованный keystore | Средняя | Высокая | Бесплатно |
| HSM/KMS | Высокая | Средняя | $30–100/мес |
Стек и реализация
Основа — 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). Документируем 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.
Получите консультацию: свяжитесь с нами для анализа вашего кейса — мы подберём оптимальное решение.