How Does a Sandwich Bot Work? Step-by-Step Logic

A sandwich bot works in a loop: watch pending transactions, filter for swaps big enough to move a pool, simulate the before-and-after trade, check that the profit beats the costs, then submit both legs so they land around the victim’s swap. If any check fails, a well-built bot skips the opportunity.

Stage 1: Watching the queue

Everything starts with visibility. On Ethereum-style networks, pending transactions propagate through a public pool before a block is built, and bots run nodes or use data feeds to read it. On Solana the flow is different, with no single global mempool in the Ethereum sense, so searchers rely on other infrastructure and relationships, which we discuss in the Solana sandwich bot guide.

CryptoMEV Bot’s product page describes the same first stage: real-time analysis of mempools and order books. Any serious tool needs low-latency data, because an opportunity that is a few hundred milliseconds old may already belong to somebody else.

Stage 2: Filtering for viable victims

Most pending transactions are not worth touching. The bot decodes each one to see whether it is a swap on a pool it understands, then screens on:

• Trade size relative to pool depth, since small trades barely move the price.
• Slippage tolerance, which sets the room available. The vendor page says its bot targets large swaps with high slippage tolerance.
• Token characteristics, including whether the token can actually be sold again. Tokens with transfer taxes or sell restrictions can turn a profitable-looking trade into a trap for the bot itself.
• Gas or fee level of the victim, which affects where the bot must place its own transactions.

Stage 3: Simulating the sandwich

The bot replays the pool’s state locally. It simulates its own front-run, then the victim’s swap at the worse price, then its back-run, and records the resulting balance. It will often test several front-run sizes to find the one that extracts the most while keeping the victim’s swap valid, because a victim who reverts leaves the bot holding an unwanted position.

The vendor page summarises this gate as simulating whether the slippage profit exceeds the gas costs of the two transactions. That is the central economic test, and we examine the margins in are sandwich bots profitable.

Key takeaway: a sandwich bot is mostly a simulator with a fast submission path. The clever part is deciding when not to trade.

Stage 4: Ordering the transactions

The bot must make sure its first transaction lands before the victim’s and its second lands right after. There are two broad ways to do that.

Method	How ordering is influenced	Main trade-off
Fee bidding	Higher priority fee ahead of the victim, lower after	Visible to rivals, can start bidding wars, failed legs cost gas
Bundles via a block-building relay	Transactions submitted together with a payment to the builder or validator	Atomic: all or nothing, but access and tip economics apply

On Solana, Jito’s documentation describes bundles and tips paid to validators, and CryptoMEV Bot’s Solana page says its software supports submitting transactions through Jito bundles for private, atomic execution. On Ethereum, builder relays offer an equivalent. The advantage of a bundle is that a failed leg does not leave the operator holding half of a position. The cost is the tip, which competition tends to push upwards.

Stage 5: Settlement and accounting

After the back-run, the bot’s balance should return to its starting asset, ideally larger. Operators then reconcile: gross gain, minus gas, minus tips, minus losses on attempts that failed. Dashboards in commercial products, such as the performance dashboard the vendor lists, exist because without careful accounting it is easy to mistake gross gains for profit.

A worked checklist an operator would run per opportunity

Before any capital moves, a disciplined operator’s software walks through a short list, and it is useful for readers to see how mundane it is.

1. Is the pending transaction a swap on a venue the bot has verified code for?
2. After removing the victim’s own price impact, how much headroom does their minimum-output setting leave?
3. What is the largest front-run that keeps the victim’s swap valid with a safety margin for state drift?
4. After subtracting the fee or tip for both legs, is the expected remainder positive by more than the model’s error band?
5. Can the token be sold back through the same route, with no transfer tax or blocklist surprises?
6. Does the opportunity still exist at the moment of submission, or has pool state moved?

If any answer is no, the bot passes. This is why an inactive bot is often a healthy one, and why raw activity counts are a poor measure of quality. A tool that fires on everything is more likely to be donating to rival searchers than extracting value.

Why infrastructure matters more than strategy

The logic above is widely known. What differs between operators is speed of data, quality of simulation, access to ordering channels and the discipline of the filters. That is why commercial products emphasise automated pre-built strategies, dashboards and, at the top end, self-hosted infrastructure with a dedicated manager, as the vendor page lists for its Enterprise tier. For an individual, the lesson is that the code is the easy part; staying competitive is the hard part. We look at that trade-off in build or buy a sandwich bot.

Where the loop breaks

The failure modes are worth knowing because they define the risk:

1. Latency. Another bot gets ahead and takes the opportunity, leaving yours to execute at a loss or revert.
2. Stale simulation. Pool state changed between simulation and inclusion.
3. Victim reverts. The victim’s transaction fails, so the back-run sells into an unfavourable price.
4. Fee escalation. Competition pushes tips high enough to wipe out the margin.

We list the full set in sandwich bot risks. For the ordering definition and the closely related tactic, sandwich attack vs front-running is a quick companion read.

What a bot cannot do

It cannot guarantee a price, create profit where the victim left no headroom, or operate outside the ordering power it can buy or earn. It also cannot make the activity risk-free in legal terms, a topic covered in is sandwich trading legal. Anyone evaluating a product should ask what the software does at each of these five stages, what it assumes about infrastructure and what it leaves to the operator.

How vendors describe the product

Reading a vendor page against these five stages is a useful exercise. CryptoMEV Bot’s sandwich bot page gives a three-step user flow: connect a wallet, configure a strategy, deploy and monitor. Behind that, it describes the mempool monitoring, the simulation gate and the risk controls such as stop-loss and position management. It does not publish performance figures or supported chains, so the stages above are a guide to what you should ask about, not a description of its internals. The company’s companion piece on what an MEV bot is places sandwiching alongside arbitrage and liquidations, and its front-run bot page covers the sibling tactic.

This article is educational and not financial or legal advice.