Розробка снайпер-бота для запуску токенів
Уявіть: нова монета виходить на Uniswap, ліквідність додана, але ви дізнаєтесь про це через 10 секунд — ціна вже зросла в 3 рази. Sniper-бот вирішує цю проблему. Різниця між входом на блоці N та блоці N+3 може означати 5x проти 1.2x. Ми будуємо снайпер-бота — інфраструктуру для гарантовано раннього входу: моніторинг mempool, детекція події лістингу та відправка транзакції з правильним gas price протягом мілісекунд. За останні кілька років ми реалізували 30+ таких проєктів під різні мережі. Помилка при ручному вході може коштувати $5000 за одну хвилину — детекція honeypot і tax автоматично заощаджує цю суму. Правильне налаштування мемпулу та газ-стратегії дозволяє випереджати конкурентів на 2–3 блоки.
Де втрачаються гроші без правильного бота
Наївний підхід — слухати подію PairCreated від Uniswap factory і відправляти swap. Проблема: на момент, коли подія потрапила в блок, минуло вже 2–5 секунд. Конкуренти читають мемпул напряму і бачать addLiquidity транзакцію ще до її включення в блок.
Другий поширений провал — податкові токени (tax tokens). Контракт з _transfer override утримує 10–30% при покупці, але не видно через стандартний ABI. Honeypot-токени блокують продаж — sell ревертиться. Детекція honeypot автоматично скасовує такі угоди, заощаджуючи тисячі доларів на одній угоді.
Чому моніторинг мемпулу критичний?
Підключення напряму до ноди через WebSocket (eth_subscribe("newPendingTransactions")) дає pending транзакції до включення в блок. Для EVM-мереж використовуємо приватний RPC з доступом до мемпулу (Chainstack, Alchemy). На Solana — logsSubscribe з фільтром за program ID Raydium або Orca. Приватна нода в 5 разів швидша за публічну: латентність 0.3–1 секунда проти 2–5 секунд.
Як працює симуляція перед покупкою?
До відправки реальної транзакції — симуляція через eth_call або tenderly_simulateTransaction. Перевіряємо:
- Реальну кількість токенів після transfer (детектуємо tax)
- Можливість продажу (чи ревертиться sell)
- Наявність blacklist/whitelist функцій
async function simulateBuy(tokenAddress: string, amountIn: bigint): Promise<SimResult> { const balanceBefore = await getTokenBalance(tokenAddress, botAddress); let expectedOutput = await getAmountOut(amountIn, tokenAddress); await provider.send('eth_call', [{ from: botAddress, to: ROUTER_ADDRESS, data: encodeSwapExact(WETH, tokenAddress, amountIn) }, 'pending']); const balanceAfter = await getTokenBalance(tokenAddress, botAddress); const received = balanceAfter - balanceBefore; const taxRate = 1 - Number(received) / Number(expectedOutput); return { received, taxRate, isSafe: taxRate < 0.05 }; } Що робити з газ-стратегією?
Для мереж з EIP-1559 (Ethereum, Polygon): maxPriorityFeePerGas виставляємо в 2–3x від поточного baseFee + aggressiveTip. Для BSC (legacy gas): моніторимо поточний gasPrice конкурентів і виставляємо на 10–20% вище. Антиgrief захист: ліміт газу на операцію, не безлімітний.
Порівняння типів нод
| Параметр | Публічна нода | Приватна нода (Alchemy/QN) |
|---|---|---|
| Латентність мемпулу | 2–5 секунд | 0.3–1 секунда |
| Доступ до pending txs | Обмежений | Повний |
| Надійність | Середня | Висока (SLA) |
| Вартість | Низька | Вища, але окупається |
Друге порівняння: ручний вхід проти бота.
| Характеристика | Ручний вхід | Sniper-бот |
|---|---|---|
| Час реакції | 3–10 секунд | 0.5–1 секунда |
| Детекція tax токенів | Ні | Симуляція + автоскасування |
| Захист від honeypot | Ні | Перевірка sell перед покупкою |
| Газ-оптимізація | Ручне налаштування | Автоматичний розрахунок на основі mempool |
Що входить в роботу
- Аналітика: вибір мережі, DEX, параметри ризику.
- Проектування: архітектура бота, конфіги, симулятор.
- Реалізація: Core-логіка на TypeScript + viem, інтеграція з нодою.
- Тестування: форк-тести на Tenderly, симуляція лістингів.
- Деплой: на ваш сервер або хмару (AWS, Hetzner).
- Документація: README, опис конфігів, приклади запуску.
- Підтримка: 1 місяць консультацій після здачі.
Розробка ведеться під ключ: ви отримуєте готового бота з інструкцією. Замовте розробку снайпер-бота — зв'яжіться з нами для індивідуального розрахунку.
Стек та архітектура
- TypeScript + viem — core логіка бота
- ethers.js — fallback для provider quirks
- WebSocket до приватної ноди — mempool підписка
- Redis — кеш already-seen транзакцій, anti-double-buy
- PostgreSQL — лог всіх операцій, P&L
Конфігурація через .env: RPC endpoint, private key в HSM або KMS, параметри ризику (max buy amount, max tax tolerance, stop-loss). Детальна документація включена.
Приклад конфігурації
# .env RPC_URL=https://eth-mainnet.g.alchemy.com/v2/your_key WS_URL=wss://eth-mainnet.g.alchemy.com/v2/your_key PRIVATE_KEY=your_private_key MAX_BUY_AMOUNT=2 ETH MAX_TAX_TOLERANCE=0.05 STOP_LOSS=0.8 Типові помилки при розробці снайпер-бота
- Використання публічних RPC: затримка 2–5 секунд вбиває перевагу.
- Відсутність симуляції перед покупкою: покупка токена з податком 30% без можливості продажу.
- Фіксована ціна газу в умовах мережевого перевантаження: транзакція зависає.
- Ігнорування блокування контракту (pause): бот купує токен, який заморожено.
- Відсутність логування та моніторингу: неможливо відлагодити втрату коштів.
Орієнтири за термінами
Базовий sniper для однієї DEX та однієї мережі — 3–5 днів. Мультичейн версія з детектором honeypot та tax-симулятором — 1–2 тижні. Вартість розраховується індивідуально. Якщо хочете обговорити проєкт або замовити розробку — зв'яжіться з нами. Отримайте консультацію з налаштування снайпер-бота прямо зараз.