Sniper bot for tokens: mempool, simulation, gas optimization

Sniper bot development: why orders lose in the mempool

A token has just appeared in the liquidity pool, and in the first seconds dozens of bots enter it simultaneously.

An order goes into the mempool — the shared queue of unconfirmed transactions — and competition for a block begins: the slot goes not to the one who pressed the button earlier, but to the one whose transaction reached validators faster and with a higher gas price.

Losing on entry price looks mundane: the trade goes through, but at a rate that has already moved up, or it is canceled — the liquidity has been bought out by then.

The root of the problem is transaction send latency: while the code assembles the signature, waits for the node response and confirmation, a competitor sends the packet to several addresses at once and takes the block.

A bot without control over this latency buys at the worst price not occasionally, but systematically.

The trickiness is that the failure is not visible in a test environment: locally everything runs instantly, while on the real network every extra operation before sending is a lost slot in a block.

The failure looks like “the market didn’t let us in,” although the decision was made slowly and on stale data. The entry moment cannot be replayed: the cost of a mistake is locked in for the entire life of the position.

We break down how this is addressed in sniper bot development — from transaction preparation to confirmation.

What managed execution provides: speed, hit rate, failures

Managed execution is not a “fast script” but a loop of four links: a mempool listener, local simulation on a copy of the current Ethereum state, transaction assembly and signing, and sending through several independent paths. Each link is responsible for its own metric and fails in its own way.

We measure reaction time to an event not from the moment the token was “noticed,” but from the appearance of the transaction in the pending queue.

We keep the node state warmed up in advance, assemble the transaction payload without intermediate calls, and perform signing and serialization in a single thread. The reaction fits within fractions of a second — enough to land in the same block, not the next one.

The share of executed orders is determined by simulation: before sending, we run the trade on a copy of the current state and discard options where the target has already been bought out, the swap route is empty, or the transaction will definitely revert.

This eliminates most idle attempts and keeps the entry price close to the price of the initiating event, rather than at the peak of the impulse.

We separately track failure classes. Failures due to stale state, insufficient gas, and resending with the same nonce go away. What remains are those dependent on competition: someone else’s block overtook us, or liquidity was taken before inclusion. We do not hide them but mark them in the log — they show exactly where the loop loses speed.

The result: an order either executes at the expected price or is recorded with a clear failure reason. Next, we break down what such a loop is assembled from and what remains on the client’s side.

Liquidity tracking methods: comparison of approaches

Liquidity tracking is not decided by the buy logic, but by how early the bot sees the pair appear and manages to land in the same block. Below are four schemes — how each is built, what task it suits, and where it runs into infrastructure and privacy constraints.

The working configuration is a combination: an observer node provides the earliest stream, an event trigger covers risk control, and a private channel handles delivery. Describe your trading scenario — we will return with an estimate and an assembly plan.

Implementation stages: from stream audit to handover of procedures

We structure sniper bot work so that contentious points are exposed before real funds are used. Each stage closes with a control point — an artifact that shows whether it is possible to proceed.

What we check at each step

1. Transaction stream audit. We analyze how target launches occur: which contracts gain access first, with what delay the event arrives, and where time is lost between an order appearing in the queue and its inclusion in a block. Control — a route diagram with marked bottlenecks.
2. Solution design. We separate event subscription, decision-making, and sending so that a failure in one block does not stop the others. Control — a diagram with failure zones and the maximum load for each part.
3. Access setup. We connect primary and backup channels to the network and fix thresholds for order size, allowable slippage, and the number of simultaneous attempts.
4. Trade simulation. We run scenarios on a network state snapshot: whether the order passes at the expected price, whether protection against sharp moves triggers. Control — a report on the share of successful runs and a breakdown of rejected ones.
5. Test network. We test the full cycle on a public environment, including stopping, restarting, and rolling back settings.
6. Handover of procedures. We provide documentation: how to cancel a stuck order, disable the bot, and change limits without a developer.

Control points give the client the right to stop work at any step. By the time it goes to mainnet, the bot’s behavior is already known from simulations and the test environment — launch stops being a lottery.

What we hand over: configurations, diagrams, policies, procedures

We deliver the project not as a “look how it works” demo, but as a set of artifacts in your repository.

An engineer on your team or a maintenance contractor deploys the loop according to the documentation and reproduces the bot’s behavior exactly — without correspondence with the author.

• Loop configuration — profiles for mainnet and an isolated testbed: gas thresholds, trade size limits, number of attempts, and pauses between them. Edited in one file, without code changes.
• Transaction flow diagram — the path from detecting a candidate in the mempool to confirmation or cancellation: where simulation is calculated, at what moment signing occurs, which branches trigger on failure and transaction replacement.
• Key access policies — where signing keys are stored, who receives them and how, how rotation works, and how operator and administrator roles are separated.
• Simulation scenarios — runs on historical blocks: competition for liquidity, sharp gas growth, rejected transactions. Repeated before every logic update.
• Metrics and alerts — successful hit rate, time from detection to confirmation, and triggering of safeguards and limits.
• Maintenance documentation — procedure: actions for a stuck transaction, node degradation, and the order of rolling out a new version and rolling back to the previous one.
• Acceptance checklist — a set of checks by which you accept the work and repeat them after every configuration change.

Case study: token launch, executed order rate increased severalfold

The client — a team launching a token on the Ethereum mainnet — came with a task where more than half of orders did not reach a block.

At the moment trading started, dozens of transactions entered the pool simultaneously, our sniper bot queued up and lost: the failure rate stayed at 30–40%, and entry price slippage reached 15%.

The cause was not the script’s speed, but that the logic did not look at the mempool and did not check the result before signing.

What we changed in the architecture

We rebuilt the scenario into three loops. The first is a mempool listener: it tracks pair creation and the first orders instead of waiting for block confirmation.

The second is trade simulation on a local copy of the network state before sending: it shows the final entry price and whether the fee is sufficient.

The third is fee management: a base rate plus a priority premium for the current load, and automatic transaction replacement if it did not get into a block.

What the result was

After moving checks into the simulation loop, the failure rate dropped to 4–6%, and the share of executed orders increased severalfold on the same launches.

Price slippage narrowed to 0.5–1.2%: some trades are cut off by simulation before sending, when conditions are worse than the set threshold.

This implementation case is illustrative because the bottleneck turned out to be not signing speed, but the lack of a check before it — predictable entry into the pool and managed risk instead of blind retries.

How sniper logic differs from arbitrage

Infrastructure-wise, both loops rest on the same foundation: an own node, mempool subscription, pre-simulation of the transaction on the current chain state, ordering management, and a shared signer.

The divergence begins at the level of the decision rule: in sniper logic, it is a reaction to a single event; in an arbitrage loop, it is continuous recalculation of arbitrage paths.

The sniper loop waits for pair creation or liquidity addition and must land in the same or next block. The decision window is fractions of a second, so filters are flat: creator address, liquidity threshold, checking sell restrictions inside the contract.

The cost of a mistake is entering an illiquid token; hence the emphasis on simulation and whitelists instead of complex analytics.

The arbitrage loop runs continuously and compares prices across several pools at once. What matters is not the speed of a single shot, but throughput: how many arbitrage paths were recalculated per block and how many of them remained profitable after the network fee and slippage.

This also leads to a different attitude toward failures — arbitrage treats a revert as a standard mode, while sniper does not allow it.

In practice, on Ethereum-class networks, the node, simulator, and transaction executor are transferred from one loop to another — they are compatible.

The decision layer and gas policy are rewritten: the sniper needs a buffer for guaranteed inclusion in a block, while arbitrage needs the limit recalculated on every iteration.

Technical concerns: network fees, limits, private channels

Concerns at the contractor selection stage almost always relate not to entry logic, but to bot behavior under load: network fee, node limits, order visibility, and key access. Below are direct answers to each point.

Will we hit node limits during a spike?

Sending goes through several independent nodes with request distribution, and the queue is spread across payer accounts so as not to run into a single sequence of nonces. A node lagging behind the current block is automatically removed from rotation.

How private is sending?

In the public mempool, an order is visible before it gets into a block — others manage to read and front-run it.

Critical entries go through a private channel directly to block builders: the transaction appears in the public list only after inclusion, when there is nothing to front-run.

How are keys protected?

Keys are not stored in plaintext and do not leave your loop: signing is performed in an isolated service, and only the finished transaction goes out. Access is role-separated, and key operations are logged.

Let's discuss the task: what is needed to start and how we assess risks

So that the start of work does not turn into a series of guesses, we need a minimum of input data. A sniper bot is not a separate program but a chain of “event source — selection logic — transaction signature,” and the weak link in this chain is visible only on a live network. That is why we collect project input data before the estimate, not after.

What we need from you at the start:

• network and launch scenario: new pair, exchange listing, re-entry into an existing pool;
• addresses of target contracts or rules by which the bot selects tokens itself;
• node access: your own or provider-based, with what request limits and mempool history depth;
• wallet and signing model: where the key is stored, who confirms each transaction;
• risk boundaries: maximum position size, allowable slippage, number of attempts per signal;
• target metrics: share of transactions brought to inclusion, time from event detection to sending;
• who on your side is responsible for funds and the legal framework for working with tokens.

After the review, we return with a stage-by-stage estimate, a work plan with control points, and a list of risks — separately for each class: simulation did not pass, the transaction was overtaken in the queue, gas price rose between calculation and sending. We also describe how we will test the logic on a test network before real funds are deployed.

Describe the task in free form — we will return with an estimate, a plan, and a list of risks.