In our piece on how a token’s price actually works we showed that buying climbs the price (slippage). Front-running is what happens when a bot weaponizes that fact against you. To see how, you first need to know where your transaction goes before it’s mined.
The mempool: a public waiting room
When you submit a swap, it doesn’t execute instantly. It lands in the mempool - a holding area of pending transactions that every node, and every bot, can read. Your trade sits there, in the clear, for a few seconds before a validator includes it in a block.
That visibility is the whole opening. A bot sees exactly what you’re about to do - which token, how much, and how much slippage you’ll tolerate - and can act on it before your trade is mined, because it can pay a higher fee to be ordered first. This is front-running, and its most common retail-facing form is the sandwich attack.
The sandwich, step by step
A sandwich wraps your trade between two of the bot’s:
- Front-run (buy): the bot sees your incoming buy and buys first, pushing the price up.
- Your trade: executes at that inflated price - so you get fewer tokens than you expected.
- Back-run (sell): the bot sells right after, into the price your buy lifted, and books the difference.
You paid more, got less, and the gap went straight to the bot. Plotted, the price walks up while the bot and you buy, then drops when the bot exits - your buy is the peak you’re trapped at:
The same pool, with numbers
Take the pool from the AMM article: 1,000 tokens / 1,000 ETH, price 1.00, invariant x · y = 1,000,000. You want to buy with 100 ETH, and you set a generous slippage tolerance so the trade doesn’t fail.
Without a bot, your 100 ETH would get you 90.9 tokens (the pool moves to 909 / 1,100).
With the sandwich:
| Step | Pool after | Result |
|---|---|---|
| 1. Bot buys (100 ETH) | 909 / 1,100 | bot gets 90.9 tokens, price → 1.21 |
| 2. Your buy (100 ETH) | 833 / 1,200 | you get 75.8 tokens (not 90.9), price → 1.44 |
| 3. Bot sells (90.9 tokens) | 924 / 1,082 | bot gets 118 ETH back |
The bot put in 100 ETH and walked away with ~118 - a ~18 ETH profit (minus gas), in the same block, risk-free. And it came from you: you received 75.8 tokens instead of 90.9, about 17% fewer, for the same money. Your slippage tolerance was the budget the bot extracted.
Why retail is the target
The bot can only sandwich you up to the slippage you allow. Wallets often default to a loose tolerance (or let you crank it to make a stuck trade go through), and on a thin-liquidity token - exactly the kind scams launch - even a small front-run moves the price a lot. Big tolerance + thin pool = a wide, easy sandwich. It’s the same low-liquidity weakness that makes rugs and honeypots cheap to run.
How to avoid being the filling
- Tighten slippage. Set the lowest tolerance the trade will accept (often 0.5-1% on a liquid pair). A tight cap shrinks the bot’s room to almost nothing; if the trade reverts, that’s information.
- Avoid thin pools. If a token’s liquidity is tiny, every swap - yours and the bot’s - moves the price hard. Check the pool depth before you trade.
- Use a private route. Submitting through a private RPC / MEV-protected relay keeps your pending trade out of the public mempool, so bots can’t see it coming.
Where RektRadar fits
The mempool is also where we watch. Our mempool monitoring sees pending transactions in real time - the same feed the bots use - to flag suspicious patterns around new tokens before they hit a block. The price on screen is one thing; what’s about to happen to it in the next block is another, and most of the damage to retail lives in that gap.
Paste any Ethereum token into the free rug pull detector at app.rektradar.io to check its liquidity and risk before you trade - a thin pool is both a rug risk and a sandwich risk.