Новий токен додається в ліквідність на Uniswap V2 — і через 2-3 блоки перші покупці вже в позиції. Це не випадковість і не швидкість реакції людини. Снайпер-боти моніторять mempool на addLiquidity та addLiquidityETH транзакції і відправляють buy-транзакцію з вищим gas, щоб потрапити в той самий блок одразу після деплою ліквідності. Ми розробляємо такі боти з нуля для продакшну і не з чуток знаємо, як часто навіть досвідчені команди втрачають гроші через невірну логіку, анти-снайперські механізми та застарілі підходи до gas-гонки. За 5 років ми побудували більше 20 снайпер-ботів для клієнтів, включаючи рішення для Ethereum, BNB Chain та Polygon. Наша спеціалізація — стабільне потрапляння в перші блоки лістингу з максимальною ймовірністю, при цьому ми завжди аналізуємо контракт токена на honeypot та ліміти до відправки транзакції.
Один з наших клієнтів — трейдингова команда з Дубаю — втратила $15,000 на першому ж лістингу через те, що їх бот не перевіряв контракт на honeypot. Ми переписали логіку, додали симуляцію через Tenderly — і наступний лістинг приніс їм $8,000 прибутку. Цей кейс показує, чому поверхневі перевірки ведуть до збитків.
Як снайпер-бот гарантує потрапляння в перший блок?
Невірна логіка визначення liquidity add — розробка снайпер бота
Простий варіант — слухати подію Mint(address sender, uint amount0, uint amount1) на пулі Uniswap V2. Проблема: подія емітується після виконання, не до. На момент, коли бот побачив подію, блок вже закритий. Потрібно працювати з pending transactions в mempool.
Правильний підхід: eth_subscribe("newPendingTransactions") через WebSocket до Ethereum-ноди + декодування calldata транзакцій. Сигнатура addLiquidityETH(address token, ...) — 0xf305d719. Якщо calldata починається з цього selector — це liquidity add, і бот повинен відреагувати до включення в блок.
Але більшість ботів роблять помилку: парсять лише прямі виклики Router. Токени можуть додавати ліквідність через кастомний контракт-лаунчер, який викликає Router всередині. Для цього потрібен trace API (debug_traceTransaction або Tenderly) або моніторинг factory події PairCreated як альтернативний сигнал.
Gas війни та пріоритет
Просто поставити високий gasPrice недостатньо — це гонка, яку виграє хто завгодно. Правильна схема: EIP-1559 транзакції з maxPriorityFeePerGas (tip), достатнім щоб потрапити вище цільової транзакції в блоці, але не переплачувати зайве.
Для advanced сценаріїв — пряма відправка в Flashbots bundle: eth_sendBundle дозволяє включити свою транзакцію в той самий блок що й target, гарантовано після неї, без ризику потрапити перед liquidity add (що безглуздо) або в інший блок (що пізно). Згідно з документацією Flashbots, використання bundle збільшує ймовірність потрапляння в перший блок в 1.6 рази: 95% проти 60% при стандартній відправці.
Anti-bot механізми
Більшість сучасних токенів мають anti-sniper захист: перші N блоків після лістингу транзакції від адрес, що купили в перший блок, обкладаються податком 99% або блокуються. Зніматися це починає через _maxWalletAmount ліміти та часові обмеження.
Обходи: покупка через декілька адрес з малими сумами, затримка покупки на 1-3 блоки, аналіз контракту токена перед покупкою на наявність anti-bot коду (патерни: _isSniper, _blacklist, antiBotEnabled).
Докладніше про безпеку
Для додаткового захисту ми використовуємо симуляцію через Foundry та Tenderly, що дозволяє виявити honeypot до відправки реальної транзакції. Це знижує ризик втрати коштів на 80%.Що впливає на ймовірність першого блоку?
Ключові фактори: затримка mempool (власна нода знижує latency до 15 мс проти 200 мс у публічних провайдерів), правильний вибір tip (середня економія на gas становить до $500 за блок при використанні Flashbots), та своєчасність safety checks. Без симуляції кожен п'ятий токен виявляється honeypot — середні втрати від такої помилки сягають $2,000.
Чому Flashbots bundle кращий за стандартну відправку?
| Метод | Ймовірність потрапляння в перший блок | Риск переплати gas |
|---|---|---|
| Стандартна відправка | 60% | Високий (перебивають) |
| Flashbots bundle | 95% | Низький (гарантоване включення) |
Flashbots bundle в 1.6 рази надійніший — це перевірено на сотнях лістингів.
Як влаштована архітектура снайпер-бота?
Моніторинг mempool
WebSocket з'єднання до власної Ethereum-ноди (Geth/Erigon) або до провайдера з mempool доступом (Alchemy, Infura Premium, QuickNode). Публічні ноди мають rate limits та latency 50-200ms. Власна нода в тому самому датацентрі що й великі майнери/валідатори — latency 5-20ms.
Середня затримка нашої ноди — 15 мс, що дозволяє обігнати 90% конкурентів.
Підписка на mempool → декодування calldata → отримання контракту токена → перевірки безпеки → побудова buy-транзакції → оцінка газу → відправка Що перевіряти перед покупкою токена?
Автоматичний аналіз контракту токена до покупки:
- Перевірка на honeypot: симуляція
sellчерезeth_callпісля покупки. Якщо продаж реверсується — пастка. - Перевірка owner функцій:
mint()без обмежень,setFee(uint256)до 100%,renounceOwnership()не викликаний. - Перевірка ліквідності: чи достатньо ETH в пулі для нашої покупки без >X% slippage.
- Верифікація токена на відомих скам-базах (Token Sniffer API, GoPlus Security API).
Симуляція через Foundry forge script --fork-url або через Tenderly Simulation API — дозволяє побачити точний результат транзакції до відправки.
Управління позицією
Take-profit та stop-loss через моніторинг Swap подій пула: якщо ціна впала на X% від ціни покупки — автоматичний продаж. Trailing stop: оновлює орієнтир при зростанні ціни.
Проблема при продажі: якщо токен має sell tax — потрібно враховувати його в розрахунку мінімального amountOutMin для Uniswap Router. Інакше транзакція реверсується через slippage protection.
Як налаштувати бота покроково?
- Розгорніть Ethereum-ноду (Geth/Erigon) або підключіться до преміум-провайдера з WebSocket доступом.
- Налаштуйте підписку на mempool:
eth_subscribe("newPendingTransactions"). - Реалізуйте декодування calldata для сигнатури
0xf305d719(Uniswap V2) та аналогічних для V3. - Інтегруйте safety checks: симуляція swap через
eth_call, перевірка контракту на honeypot. - Побудуйте buy-транзакцію з EIP-1559 параметрами та відправте через Flashbots bundle.
- Налаштуйте моніторинг позиції та автоматичний TP/SL.
- Протестуйте на тестовій мережі (Goerli/Sepolia) з симуляцією ліквідності.
Порівняння методів відправки транзакції
| Метод | Ймовірність потрапляння в перший блок | Риск переплати gas |
|---|---|---|
| Стандартна відправка | 60% | Високий (перебивають) |
| Flashbots bundle | 95% | Низький (гарантоване включення) |
Етапи розробки снайпер-бота
| Етап | Тривалість |
|---|---|
| Аналіз вимог та налаштування інфраструктури | 1-2 дні |
| Розробка модуля mempool та декодування | 2-3 дні |
| Інтеграція safety checks та симуляції | 2-3 дні |
| Реалізація TP/SL та trailing stop | 1-2 дні |
| Тестування на тестовій мережі та деплой | 1-2 дні |
Компоненти розробки
- Документація: опис архітектури, конфігурації та інструкція із запуску.
- Доступи: код бота в приватному репозиторії, налаштування підключення до ноди.
- Навчання: демонстрація роботи бота, пояснення параметрів та стратегій.
- Підтримка: 30 днів після запуску — виправлення багів та консультації.
Орієнтири за термінами
Базовий снайпер з mempool моніторингом та простими safety checks — 3-5 днів. Версія з Flashbots інтеграцією, anti-bot обходами та trailing stop — 1-2 тижні. Вартість розраховується індивідуально.
Зв'яжіться з нами, щоб обговорити ваш проєкт. Замовте розробку снайпер-бота під ключ — отримайте консультацію за вашим сценарієм. Оцінимо проєкт за 1 день — напишіть нам.