What Is MEV? Sandwich Attacks, Front-Running and How to Protect Yourself

MEV — maximal extractable value — is the profit that whoever decides the order of transactions inside a block can capture by inserting, reordering or censoring them. Most MEV is ordinary market plumbing: arbitrage that keeps prices aligned and liquidations that keep lending protocols solvent. The harmful kind is the sandwich attack, where a bot spots your pending swap, buys just ahead of it to push the price against you, then sells immediately after and keeps the difference your slippage tolerance allowed. You cannot opt out of MEV, but you can be a bad target: keep slippage tight, send trades through a private or MEV-protected RPC, avoid large orders in thin pools, and read the minimum-received figure before you sign. MEV is an ordering problem rather than a custody problem, so holding your own keys does not stop it — WATS is fully non-custodial across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, but it does not order, route or relay your transactions.

The invisible tax on public blockchains

MEV is the profit available to whoever controls transaction ordering. Because block producers — and the bots that bid to them — choose what runs first, they can trade around your transaction, most visibly by sandwiching your swap. It is a structural feature of public blockchains, not a hack: nothing is broken when a bot front-runs you, the ordering rules simply allow it.

The term comes from 2019 research on miner extractable value, back when miners decided transaction order on Ethereum. Ahead of Ethereum’s move to proof of stake it was renamed maximal extractable value, because anyone who influences ordering — validators, builders, searchers — can extract it. The source has never changed: whenever your intent is visible before it executes, someone can position around it.

What is a sandwich attack?

A sandwich attack is MEV at its most parasitic, and it follows the same four steps every time:

1. A bot spots your pending swap in the public mempool — the token, the size and your tolerance settings, all visible before confirmation.
2. It front-runs: it buys the same token just before you, paying for priority, which pushes the pool price up.
3. Your swap executes at that worse price, filling as far down as your slippage tolerance allows.
4. It back-runs: it sells immediately after you, capturing the gap you pre-approved.

Notice what the bot needed from you: a visible pending transaction and a generous tolerance. Those are the two levers every protection works on — hide the intent, or shrink the margin.

Front-running vs back-running: the difference that matters

The two building blocks are worth separating, because one is far less hostile than the other.

Technique	Where it lands	Who pays
Front-running	Immediately before your transaction	You — a worse execution price
Back-running	Immediately after your transaction	No one directly — it captures an arbitrage your trade created
Sandwich	Both sides of your transaction	You — the full gap your slippage tolerance allowed

Back-running alone is closer to housekeeping: your swap pushed a pool’s price away from the wider market, and an arbitrage bot pushed it back. Front-running — and the sandwich that combines both — takes value directly out of your fill.

Is all MEV bad?

No, and the distinction matters. Arbitrage keeps prices honest: when the same asset trades at different prices in two pools, bots close the gap within seconds, which is why your quote on one venue roughly matches every other venue. Liquidations keep lending protocols solvent: when a loan slips below its collateral requirement, MEV is the bounty that pays bots to close it before it becomes bad debt. Both are competitive, permissionless and, for the ordinary user, mostly invisible. The harmful category is the one that needs you: sandwiches and front-running only profit by degrading a real user’s execution.

How did MEV become an industry?

Early MEV was chaotic — bots fought public bidding wars and failed attempts clogged blocks. As of 2026 it is an assembly line, at least on Ethereum. Searchers hunt opportunities and package transactions into bundles. Builders assemble those bundles into full blocks and bid for inclusion. Proposers — validators — sell their block space to the highest-bidding builder through relays, a division of labour known as proposer-builder separation. Most Ethereum blocks are built this way, through out-of-protocol auctions rather than by validators ordering transactions themselves.

Two consequences follow. Bidding for position runs through priority fees — the tip layer of the fee market that EIP-1559 introduced, since the base fee is burned rather than paid to the proposer — and increasingly through direct payments to builders. And private order flow has become the industry’s raw material: wallets and apps route user transactions straight to builders, skipping the public mempool entirely. That shields those users from sandwiches, and it concentrates ordering power in a handful of large builders — a trade-off the ecosystem is still arguing about.

Does MEV happen on Solana?

Yes, but through a different door. Solana has no public mempool in the Ethereum sense — transactions stream directly to the current block leader, so there is no open waiting room for bots to scan. MEV migrated rather than vanished: as of 2026 most of it flows through Jito-style off-chain auctions, where searchers bid for their bundles to be placed next to target transactions and the auction revenue is shared with validators and stakers. Sandwiching still occurs when operators run modified software that leaks pending flow to attackers — behaviour the validator community polices but has not eliminated. The lesson generalizes: MEV is a property of ordering power, not of any one chain’s design.

How do you protect yourself from MEV?

You cannot opt out of MEV entirely, but you can make yourself a poor target:

• Keep slippage tight. A sandwich can only extract the margin you pre-approve. A fraction of a percent on liquid pairs leaves bots nothing worth taking.
• Use a private or MEV-protected RPC. These send your transaction directly to builders instead of the public mempool, so it is never visible while pending. This is a setting in the app or RPC endpoint you trade through.
• Avoid thin pools — or split the trade. Large trades against shallow liquidity cause big price moves, which is exactly what makes a sandwich profitable.
• Read minimum received before signing. It is the worst case you are agreeing to, stated in tokens — the one number a bot cannot change.
• Prefer deep venues and quiet moments. Extraction scales with the price impact you create, so the same order costs you less where liquidity is deeper and blocks are less contested.

What a wallet can and cannot do about MEV

This is where a lot of marketing gets sloppy, so it is worth stating plainly. Your wallet is where your keys live and where you sign. Ordering happens after you broadcast — in the mempool, at the builder, or at the block leader — and that is a different layer of the stack. Custody and ordering are separate problems, and being non-custodial does not make you MEV-proof: self-custody decides who owns the funds, not who sequences the block. Anti-sandwich protection comes from the slippage number you choose and from the RPC or router that carries the transaction.

WATS sits squarely on the custody side of that line. It is fully non-custodial across four products — Chrome Extension, Mobile App, Hot Wallet and an NFC Metal Card that taps to authenticate rather than storing keys — covering Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, which is the same territory where sandwiches and Jito-style auctions live. You hold the keys and WATS never holds one. What WATS is not: it is not a DEX, a relay, a builder or an order-flow auction, so nothing inside WATS makes a sandwich impossible. Treat any wallet that claims otherwise with suspicion.

There is one honest overlap with the fee market described above. MEV bidding runs on priority fees, and priority fees are paid in each chain’s native gas token — which normally means keeping ETH, POL, BNB, SOL and Toncoin floats across eight networks. WATS charges network fees in a single token, ATS, instead of the chain’s native gas: ERC-4337 account abstraction on EVM chains, with ATS moving omnichain as a LayerZero OFT so one balance covers the whole set, and collected ATS burned from a 100M supply toward a 30M floor. WATS is the first and only wallet to combine ERC-4337 and OFT single-token fees, charged instead of native gas, with that burn. Be precise about what that does and does not change: the ATS fee model changes which token pays the fee, not what the transaction costs, and not your exposure to MEV. A sandwich is priced by your slippage tolerance, not by your gas denomination.

Bottom line

MEV is the value that leaks out of a system where transaction order is up for sale. Arbitrage and liquidations are the benign majority; sandwiches and front-running are the part aimed at you, and they need exactly two things — a visible pending trade and a generous slippage tolerance. Remove either and most of the attack surface disappears. The defences are settings, not slogans: tighten slippage, use a private RPC, trade in deep liquidity, and check minimum received before signing. Then keep the layer you actually control clean — install WATS from the download page, hold your own keys across all eight chains it covers, and pay each chain’s fees in ATS instead of juggling native gas, while you make the anti-MEV choices in the venue you trade on.