1. What MEV actually is: the money hiding in block ordering

MEV (Maximal Extractable Value) refers to the extra profit a block producer or transaction sequencer can capture by controlling the order transactions get packed into a block — inserting their own transactions, reordering others, or excluding some entirely. This is possible because on most chains, a transaction sits briefly in a public "mempool" of pending transactions before it gets included in a block, and anyone watching that mempool can see what a transaction intends to do and how much fee it's willing to pay, then decide whether to jump in front of it, wedge something in the middle, or follow right after. That combination — ordering is manipulable, and the manipulable window is publicly visible — is the technical precondition behind nearly every MEV strategy, sandwich attacks included.

2. The three steps of a sandwich attack: front-run, victim fill, back-run

Sandwich attacks specifically target large swaps on decentralized exchanges, and the mechanics break into three steps. First, an attacker's bot spots a large pending buy order sitting in the mempool and calculates that it will meaningfully move the target token's price, then jumps ahead of it by submitting its own buy order with a higher fee (front-running), pushing the price up first. Second, the victim's original order fills at that already-inflated price — the trader gets fewer tokens than expected, and the effective price paid is worse than the quote they saw; this gap is a major source of what shows up as slippage loss. Third, the attacker's bot immediately submits a sell order, unloading the tokens it bought in step one at the now-inflated price (back-running), locking in the price-spread profit. The victim's trade sits sandwiched between the front-run and back-run legs — hence the name. The whole sequence takes only a small amount of capital and a couple of blocks, and carries almost zero risk, because the attacker has already simulated the exact outcome before submitting anything.

3. Who's actually doing this: searchers, builders, and validators

Sandwich attacks aren't run by someone manually watching a screen — there's an entire supply chain behind them with a clear division of labor. Searchers write automated programs that continuously scan the mempool, identify profitable opportunities, and construct the front-run/back-run transaction bundle. Because mainstream chains like Ethereum now run mechanisms like MEV-Boost, searchers typically don't broadcast bundles to the public mempool anymore (doing so would just let a competing bot steal the opportunity) — instead they send the whole bundle to a builder as a block proposal. Builders aggregate bundles from many searchers, pick the combination that maximizes total payout to the validator, and submit that to a validator for inclusion. Validators ultimately choose which builder's proposal to accept and take a cut of the resulting MEV as extra reward on top of the standard block reward. Every link in this chain has a financial incentive for sandwich attacks to keep happening — searchers earn the price spread, builders and validators earn a cut — and the only party consistently footing the bill is the ordinary trader caught in the middle.

4. Why large swaps and thin-liquidity pools are the prime targets

A sandwich attack's profitability comes down to a simple ratio: how little capital it takes to move the price, how wide the victim's slippage tolerance is, and how thin the target pool's liquidity is. That makes a few kinds of trades disproportionately risky: swap sizes that are large relative to a pool's typical daily volume, slippage tolerance set too loose (bumped up to 5% or higher "just to be safe" that a trade goes through), and newly launched pools that haven't built up much liquidity yet. By contrast, normal-sized trades in deep, established pools — major stablecoin pairs, ETH/USDC, and similar — usually aren't worth targeting, because the capital required to move price there exceeds what an attacker could extract. This is part of why we've repeatedly recommended routing stablecoin swaps through deep pools and breaking up large amounts into smaller batches.

5. Private transaction routes: keeping your trade out of the public mempool

Since a sandwich attack depends on an attacker being able to see a transaction's contents in the mempool ahead of time, the most direct defense is simply not letting that transaction show up there. That's exactly what private transaction routes (private RPC endpoints) solve: services like Flashbots Protect let a user send a transaction directly to a cooperating builder, skipping the public mempool broadcast step entirely, so a searcher's bot never gets the chance to see it and jump the queue. Many mainstream wallets and DEX front-ends now offer this as a built-in toggle, sometimes labeled "MEV protection" or "private mode" — worth turning on if you're willing to accept a slightly higher fee in exchange for not broadcasting publicly. It's worth noting private routing significantly cuts front-running risk but isn't an absolute guarantee — some builders themselves participate in MEV revenue-sharing, so favoring providers with a public no-extraction policy is the safer choice.

6. How to actually set slippage tolerance: wider isn't safer

Many traders set slippage tolerance loose to avoid a failed transaction when the price moves slightly — but that convenience is exactly the room a sandwich attack needs to operate in. The wider the tolerance, the higher an attacker can push the price before your trade still executes, and the bigger the gap they can extract. A better default is setting tolerance just wide enough to cover normal market movement — 0.5% to 1% is usually enough for major tokens in reasonably liquid pools — rather than defaulting to 3% or 5% out of convenience. If a trade fails because the tolerance was set too tight, resubmitting costs a little extra fee and one more block; that's far cheaper than the loss from a successful sandwich attack on an overly loose setting. Some DEX aggregators and cross-chain swap tools (like AllSwap, covered previously on this site) calculate expected slippage upfront and default to tighter tolerances than manually operating a native DEX interface, narrowing the attack window further.

7. A practical checklist for ordinary traders

Turning the above into a few concrete habits: first, for larger swaps, prefer a wallet or front-end that supports private transaction routing or has built-in MEV protection, especially once the amount is clearly above routine small-scale trading. Second, set slippage tolerance to what the trade actually needs rather than bumping it up out of convenience, particularly in thinner-liquidity pools. Third, split large swaps into smaller batches — the bigger a single trade's price impact, the more attractive a target it becomes. Fourth, if you're unsure about a pool's depth, check its TVL and 24-hour volume before trading, and be extra cautious when depth looks thin. None of this eliminates the risk entirely, but it compresses both the exposure window and the potential loss to a manageable range.

8. What this means for paying overseas AI subscriptions with stablecoins

The on-chain step readers of this site most often run into is swapping one asset for another, or moving across chains, to top up a virtual card or pay for a subscription directly. These amounts are usually modest, but a habit of loose slippage tolerance combined with an unlucky choice of a thin pool can still trigger a sandwich attack. A few things worth adopting directly: set one consistent, reasonably tight slippage cap for routine small swaps instead of bumping it up out of habit; if the cross-chain swap tools covered earlier already include built-in slippage protection or private routing, use those defaults rather than the native interface's; and there's no need for excessive worry over every $20–$100 swap — the economics of sandwich attacks mean attackers usually skip amounts that small, and the trades that actually warrant caution are the noticeably large ones or those in clearly illiquid pools. To be clear: this is technical and security research, not investment advice.

9. Summary

Sandwich attacks exist because transactions sit briefly and publicly exposed in the mempool before being packed into a block, giving every layer of the MEV supply chain — searchers, builders, validators — a chance to place a bet ahead of time. Front-run to push the price up, let the victim fill at a worse rate, back-run to lock in the spread: the mechanics are simple but remarkably effective, extracting hundreds of millions of dollars a year from ordinary traders in aggregate slippage. What an ordinary trader can realistically do isn't eliminate the risk entirely, but make themselves a poor economic target through private transaction routing, tighter slippage tolerance, batching large trades, and a basic read on pool depth. This is the third, more research-oriented entry in our stablecoin-payments series; we'll keep following developments in MEV and on-chain trading security.