A new token hits liquidity on Uniswap V2 — and within 2-3 blocks, the first buyers are already in position. This isn't luck or human reaction speed. Sniper bots monitor the mempool for addLiquidity and addLiquidityETH transactions and send a buy transaction with higher gas to land in the same block right after liquidity deployment. We build such bots from scratch for production and know firsthand how often even experienced teams lose money on incorrect logic, anti-sniper mechanisms, and outdated gas bidding approaches. Over 5 years, we have built more than 20 sniper bots for clients, including solutions for Ethereum, BNB Chain, and Polygon. Our specialization is stable first-block entry with maximum probability, and we always analyze the token contract for honeypot and limits before sending the transaction.
One of our clients — a trading team from Dubai — lost $15,000 on their first listing because their bot did not check the contract for honeypot. We rewrote the logic, added simulation via Tenderly — and the next listing netted them $8,000 in profit. This case shows why superficial checks lead to losses.
How does a sniper bot guarantee first-block entry?
Incorrect logic for detecting liquidity add — sniper bot development
The naive approach is to listen for the Mint(address sender, uint amount0, uint amount1) event on the Uniswap V2 pool. Problem: the event is emitted after execution, not before. By the time the bot sees the event, the block is already sealed. You need to work with pending transactions in the mempool.
The correct approach: eth_subscribe("newPendingTransactions") via WebSocket to an Ethereum node + decoding the transaction calldata. The signature for addLiquidityETH(address token, ...) is 0xf305d719. If the calldata starts with this selector, it's a liquidity add, and the bot must react before it is included in a block.
But most bots make a mistake: they only parse direct Router calls. Tokens can add liquidity via a custom launch contract that calls the Router internally. For that, you need a trace API (debug_traceTransaction or Tenderly) or monitoring the factory PairCreated event as an alternative signal.
Gas wars and priority
Simply setting a high gasPrice is not enough — it's a race where anyone can win. The proper scheme: EIP-1559 transactions with maxPriorityFeePerGas (tip) sufficient to land above the target transaction in the block, but without overpaying.
For advanced scenarios — direct submission via Flashbots bundle: eth_sendBundle allows including your transaction in the same block as the target, guaranteed after it, without the risk of landing before the liquidity add (which is useless) or in a different block (too late). According to Flashbots documentation, using a bundle increases the probability of hitting the first block by 1.6x: 95% vs 60% with standard submission.
Anti-bot mechanisms
Most modern tokens have anti-sniper protection: the first N blocks after listing, transactions from addresses that bought in the first block are taxed 99% or blocked. This starts being lifted through _maxWalletAmount limits and time constraints.
Workarounds: buying via multiple addresses with small amounts, delaying the purchase by 1-3 blocks, analyzing the token contract before purchase for anti-bot code (patterns: _isSniper, _blacklist, antiBotEnabled).
Security details
For additional security, we use simulation via Foundry and Tenderly, which allows detecting honeypot before sending a real transaction. This reduces the risk of losing funds by 80%.What affects first-block probability?
Key factors: mempool latency (dedicated node reduces latency to 15 ms vs 200 ms for public providers), correct tip selection (average gas savings of up to $500 per block using Flashbots), and timely safety checks. Without simulation, every fifth token is a honeypot — average losses from such an error reach $2,000.
Why Flashbots bundle over standard submission?
| Method | Probability of first block | Risk of gas overpayment |
|---|---|---|
| Standard submission | 60% | High (outbid) |
| Flashbots bundle | 95% | Low (guaranteed inclusion) |
Flashbots bundle is 1.6x more reliable — proven on hundreds of listings.
How is the sniper bot architecture designed?
Mempool monitoring
WebSocket connection to a dedicated Ethereum node (Geth/Erigon) or to a provider with mempool access (Alchemy, Infura Premium, QuickNode). Public nodes have rate limits and latency of 50-200ms. A dedicated node in the same datacenter as major miners/validators — latency 5-20ms.
Our node's average latency is 15 ms, which lets us outrun 90% of competitors.
Mempool subscription → calldata decode → token contract fetch → safety checks → buy tx construction → gas estimation → send
What to check before buying a token?
Automated token contract analysis before purchase:
- Honeypot check: simulate
sellviaeth_callafter purchase. If the sale reverts, it's a trap. - Owner function checks:
mint()without limits,setFee(uint256)up to 100%,renounceOwnership()not called. - Liquidity check: is there enough ETH in the pool for our purchase without >X% slippage.
- Token verification against known scam databases (Token Sniffer API, GoPlus Security API).
Simulation via Foundry forge script --fork-url or via Tenderly Simulation API — allows seeing the exact transaction result before sending.
Position management
Take-profit and stop-loss via monitoring Swap events on the pool: if the price drops X% from the purchase price — automatic selling. Trailing stop: updates the reference when price rises.
Issue when selling: if the token has a sell tax, it must be considered in the minimum amountOutMin calculation for the Uniswap Router. Otherwise, the transaction reverts due to slippage protection.
How to set up the bot step by step?
- Deploy an Ethereum node (Geth/Erigon) or connect to a premium provider with WebSocket access.
- Set up mempool subscription:
eth_subscribe("newPendingTransactions"). - Implement calldata decoding for signature
0xf305d719(Uniswap V2) and similar for V3. - Integrate safety checks: simulate swap via
eth_call, check contract for honeypot. - Build the buy transaction with EIP-1559 parameters and send via Flashbots bundle.
- Configure position monitoring and automatic TP/SL.
- Test on a testnet (Goerli/Sepolia) with simulated liquidity.
Comparison of transaction submission methods
| Method | Probability of first block | Risk of gas overpayment |
|---|---|---|
| Standard submission | 60% | High (outbid) |
| Flashbots bundle | 95% | Low (guaranteed inclusion) |
Sniper bot development stages
| Stage | Duration |
|---|---|
| Requirements analysis and infrastructure setup | 1-2 days |
| Mempool and decoding module development | 2-3 days |
| Safety checks and simulation integration | 2-3 days |
| TP/SL and trailing stop implementation | 1-2 days |
| Testnet testing and deployment | 1-2 days |
Components included in the work
- Documentation: architecture description, configuration, and launch instructions.
- Access: bot code in a private repository, node connection setup.
- Training: bot operation demo, explanation of parameters and strategies.
- Support: 30 days after launch — bug fixes and consultations.
Timeline estimates
Basic sniper with mempool monitoring and simple safety checks — 3-5 days. Version with Flashbots integration, anti-bot bypass, and trailing stop — 1-2 weeks. Cost is calculated individually.
Contact us to discuss your project. Order a turnkey sniper bot development — get a consultation for your scenario. We'll assess your project within 1 day — reach out.