DEX Sniper Bot Development
A new token is added to liquidity on Uniswap V2 — and within 2-3 blocks the first buyers are already in position. Not by chance and not human reaction speed. Sniper bots monitor the mempool for addLiquidity and addLiquidityETH transactions, and send buy transactions with higher gas to land in the same block right after liquidity deployment.
Where typical implementations fail
Wrong liquidity add detection logic
Simple approach — listen to Mint(address sender, uint amount0, uint amount1) event on Uniswap V2 pool. Problem: the event emits after execution, not before. By the time bot sees the event, the block is closed. Must work with pending transactions in mempool.
Right approach: eth_subscribe("newPendingTransactions") via WebSocket to Ethereum node + decode transaction calldata. Signature addLiquidityETH(address token, ...) is 0xf305d719. If calldata starts with this selector — it's a liquidity add, bot must respond before block inclusion.
But most bots make a mistake: they only parse direct Router calls. Tokens can add liquidity via custom launcher contract calling Router inside. Need trace API (debug_traceTransaction or Tenderly) or monitor PairCreated factory event as alternative signal.
Gas wars and priority
Simply setting high gasPrice isn't enough — it's a race won by anyone. Proper scheme: EIP-1559 transactions with maxPriorityFeePerGas (tip) sufficient to rank above target transaction, but don't overpay.
For advanced — send directly to Flashbots bundle: eth_sendBundle lets you include your transaction in same block as target, guaranteed after it, no risk landing before liquidity add (useless) or in different block (too late).
Anti-bot mechanisms
Most tokens in 2023-2024 have anti-sniper protection: first N blocks after listing, transactions from addresses that bought in first block are taxed 99% or blocked. This lifts after _maxWalletAmount limits and time restrictions.
Bypasses: buy via several addresses with small amounts, delay buy 1-3 blocks, analyze token contract before buying for anti-bot code (patterns: _isSniper, _blacklist, antiBotEnabled).
Bot architecture
Mempool monitoring
WebSocket connection to own Ethereum node (Geth/Erigon) or provider with mempool access (Alchemy, Infura Premium, QuickNode). Public nodes have rate limits and 50-200ms latency. Own node in same datacenter as major miners/validators — 5-20ms latency.
Mempool subscription → calldata decode → token contract fetch →
safety checks → buy tx construction → gas estimation → send
Safety checks before buying
Automatic token contract analysis before purchase:
- Honeypot check: simulate
sellviaeth_callafter buying. If sell reverts — trap - Owner functions check:
mint()without limits,setFee(uint256)up to 100%,renounceOwnership()not called - Liquidity check: enough ETH in pool for our buy without >X% slippage
- Token verification on known scam databases (Token Sniffer API, GoPlus Security API)
Simulation via Foundry forge script --fork-url or Tenderly Simulation API — see exact transaction result before sending.
Position management
Take-profit and stop-loss via monitoring pool Swap events: if price dropped X% from buy price — auto-sell. Trailing stop: updates target on price rise.
Problem on sell: if token has sell tax — must account for it in calculating minimum amountOutMin for Uniswap Router. Otherwise transaction reverts due to slippage protection.
Stack
Node.js / TypeScript with ethers.js v6 or viem for network interaction. Own Ethereum node (Geth or Erigon) for mempool. Redis for cache of checked contracts. Flashbots SDK for private bundles.
For Uniswap V3 monitoring — Uniswap SDK v3 for route calculation and quoter calls.
Timeline estimates
Basic sniper with mempool monitoring and simple safety checks — 3-5 days. Version with Flashbots integration, anti-bot bypasses and trailing stop — 1-2 weeks.
Cost calculated individually.