MEV: Frontrunning, Sandwiching, and How to Protect Yourself

If you have ever swapped a token on a DEX and noticed the price you got was slightly worse than the quote you saw a moment before, you may have brushed up against MEV. MEV is one of those topics that sounds intimidating, gets sensationalized online, and rarely gets explained in terms a self-custody user can actually act on. This article fixes that. We will look at what MEV really is, where it comes from, the three patterns you are most likely to encounter, who is actually at risk, and the concrete habits that reduce your exposure when you swap from SSP.

What MEV actually means

MEV stands for Maximal Extractable Value (originally "Miner Extractable Value" before Ethereum's move to proof-of-stake). It refers to the value that can be extracted from a block by choosing which transactions to include, the order to include them in, and whether to censor any of them.

It is easiest to think of MEV as a structural property of public blockchains, not a malicious actor. Whoever decides the contents of the next block has discretion over ordering, and that discretion has economic value. Some MEV is harmless — arbitrage that keeps prices consistent across DEXs is technically MEV, and it benefits the system. Some MEV is extractive — it transfers value from regular users to sophisticated participants.

Where MEV comes from

When you send a transaction on Ethereum or any EVM chain, it does not go straight into a block. It sits in the mempool, a public waiting area visible to anyone running a node. Specialized actors called searchers scan the mempool looking for profitable opportunities. They submit their own transactions, often through builders who assemble blocks, and the validator ultimately publishes the chosen block.

After The Merge and the rollout of proposer-builder separation, the modern flow looks roughly like this:

• Searchers find an opportunity and craft a bundle of transactions.
• Builders assemble candidate blocks that maximize fee + tip revenue.
• Validators (proposers) pick the most profitable block from competing builders.

The point for users: your pending swap is visible in the public mempool unless you take specific steps. Anyone watching can react to it.

The three patterns you should know

1. Frontrunning

A searcher sees a pending transaction that will move a price in a predictable way — for example, a large swap that will push the token's price up on a DEX. They submit an identical or similar transaction with a higher tip, so it lands in the block before yours. They get the better price, and you get the slightly worse one that follows.

Frontrunning is mostly a concern for large swaps with obvious market impact, not the average retail trade.

2. Sandwiching

This is the pattern most often discussed in connection with retail users. A searcher sees your swap, calculates that it will move the price, and places two transactions around it:

1. A buy immediately before your swap, pushing the price up.
2. A sell immediately after your swap, capturing the price you just pushed.

You receive fewer tokens than you expected, and the difference goes to the searcher. The risk scales with your trade size, how shallow the liquidity pool is, and — critically — how much slippage tolerance you set. A high slippage tolerance is what makes a profitable sandwich possible at all; tight slippage either prevents the sandwich or causes your transaction to revert.

If you have not yet, the companion article on slippage and price impact explains exactly why that tolerance matters.

3. Backrunning

A searcher places a transaction immediately after yours to capture an opportunity your transaction created — typically arbitrage between pools after your swap moved a price. Backrunning generally does not hurt you (your swap already executed at the price you accepted). It is, in fact, one of the mechanisms that keeps DEX prices in line with the wider market.

It is worth knowing the difference: not every MEV transaction touching your swap is taking value from you.

Who is actually at risk

Honest answer: not every user, not every trade.

• Small swaps in deep pools — say, a $200 swap on a major ETH/USDC pool — usually move the price by a tiny fraction of a percent. The economics of sandwiching simply do not work; the searcher's gas costs would exceed the profit.
• Large swaps on shallow pools — say, a five- or six-figure swap on a small-cap token pair — are exactly where sandwich attacks become profitable. The price impact is large, slippage tolerance often has to be loose to land the trade, and the searcher's expected profit covers the gas easily.
• Anything in between depends on pool depth, the specific token pair, current congestion, and your slippage setting.

The takeaway is not "MEV is everywhere" or "MEV is rare" — it is "MEV exposure is a function of trade size, pool depth, and how loose your settings are."

What you can actually do

You cannot eliminate MEV as an individual user; it is a property of how blocks are produced. You can meaningfully reduce your exposure:

• Use tight, realistic slippage. Set slippage as low as the trade will tolerate. A 0.5–1% tolerance on a deep-pool, liquid pair is usually fine. A 5–10% tolerance is an open invitation to be sandwiched. See slippage and price impact.
• Prefer deep liquidity pools. A swap that moves a deep pool by 0.05% is not interesting to sandwich. A swap that moves a shallow pool by 5% is.
• Use a private-mempool RPC where available. Services like Flashbots Protect route your transaction to builders directly, bypassing the public mempool. Searchers cannot react to a transaction they cannot see. This is a neutral, well-known mitigation in the Ethereum ecosystem; the Ethereum docs on MEV cover the broader landscape.
• Use in-wallet swap routes that pre-quote. When you swap from inside SSP using a built-in route, the quote includes the realistic execution price; if reality drifts too far, the transaction reverts rather than silently executing against a worse price.
• Break large trades into smaller chunks. A single large swap maximizes the searcher's profit; several smaller swaps spread across time and pools reduce the per-trade incentive.
• Mind gas costs. A reverted swap still costs gas. If you set slippage so tight your transaction fails repeatedly, you are paying for nothing. See gas fees on Ethereum for sizing context.

How this relates to SSP's 2-of-2 protection

MEV is a transaction-ordering risk, not a key-compromise risk. Whether or not your transaction gets sandwiched has nothing to do with whether your keys are safe.

SSP is a 2-of-2 self-custodial wallet: every transaction is co-signed by the SSP browser extension and the SSP Key mobile app, with the ERC-4337 smart account on EVM chains using a Schnorr-aggregated signature audited by Halborn in 2025. That protection is about who can spend your funds. MEV is about who decides the order of transactions that you have already authorized.

In other words: a sandwich attack does not steal your keys, and the 2-of-2 model does not, by itself, change what you receive from a swap. The mitigations above — tighter slippage, deeper pools, private RPCs, sensible trade sizing — are the layer that protects against MEV.

A practical mental model

When you are about to swap, ask yourself three questions:

1. How deep is the pool I am swapping into? Deep pools attract less sandwich attention.
2. What slippage am I tolerating? Tight enough to make a sandwich unprofitable?
3. Is the size of this trade going to noticeably move the price? If yes, consider splitting it or routing through a private mempool.

That mental model handles the realistic majority of cases. The in-wallet swap overview walks through the swap experience itself, and the Ethereum-in-SSP guide covers chain-level context. MEV is a real cost of using open mempools, but it is a cost you can shape with a small number of habits — and one that does not change the fundamental security guarantee that 2-of-2 self-custody gives you.