Front-running
Attack where a bot spots a pending transaction in the mempool and pushes its own ahead with higher priority, profiting from the move the victim will cause.
Aliases: frontrunning, ordering attack
Front-running is a specific MEV attack. A bot watches the mempool, spots a profitable pending trade, and races ahead by submitting its own transaction at a higher fee or priority. The goal is to profit from the price move the victim is about to cause.
Classic scenario
- You send a 50,000 USDT-notional TON → USDT swap via STON.fi.
- A bot sees the transaction in the mempool and predicts the post-trade USDT price will drop.
- The bot urgently buys USDT in the same pool before your swap (its own tx at higher gas).
- Your swap executes; the pool price moves.
- The bot sells the bought USDT back at the new, more favourable price.
The price gap is the money you could have kept — captured by the bot instead.
When it works
- The target’s price moves in a predictable direction.
- Your trade is large enough for the move to cover gas and the bot’s spread.
- The mempool is transparent, letting the bot land in the same block (or close to it).
Front-run vs sandwich
Related but different attacks:
- Front-run — get in ahead of the victim and exit later.
- Sandwich — wrap the victim from both sides: buy before, sell right after.
Sandwiching is more profitable and far more common in DeFi. “Pure” front-running is rarer but lives on inside liquidator and arbitrage bots.
How to defend
- Tight slippage tolerance. With 5% slip the bot can extract close to 5%. With 0.5% the margin collapses.
- DEX aggregators. A trade split across pools is harder to predict.
- Order splitting — each chunk becomes individually less attractive.
- Private mempool / private RPC — when supported. Largely unavailable on TON today.
- Limit orders where DEXs offer them — they remove the urgency that bots exploit.
Front-running is the inherent cost of an open mempool. It cannot be eliminated, but conscious settings cut the loss substantially.