MEV (Maximal Extractable Value): How Searchers and Bots Impact Your Swaps

MEV is still a live part of Ethereum's market structure, not a historical quirk. Ethereum's official MEV documentation, last updated February 26, 2026, continues to describe searchers, block builders, validators, arbitrage, liquidations, and sandwich trading as core parts of the MEV landscape. For someone making a decentralized-exchange swap, the practical lesson has not changed: a transaction that becomes visible before execution can create an opportunity for automated actors to profit from its position or from the price movement it causes.

That does not mean every disappointing swap was “attacked,” or that all MEV is harmful. Price impact, ordinary market movement, routing, fees, and MEV can all influence execution. Understanding which is which helps you avoid blaming bots for normal DEX mechanics—and helps you recognize the situations where transaction ordering really can work against you.

A simplified sandwich-trading flow: a visible pending swap can be surrounded by bot transactions so the user's trade executes after the price has moved against it. The diagram is conceptual; actual transaction routing and block construction vary.

What MEV actually means

MEV stands for maximal extractable value. Ethereum defines it as value that can be extracted from block production beyond the standard block reward and gas fees by including, excluding, or changing the order of transactions in a block. The term originally meant “miner extractable value,” but after Ethereum moved to proof-of-stake, validators rather than miners became responsible for proposing blocks, so “maximal” became the more accurate term. See the Ethereum.org MEV documentation.

In practice, much of the opportunity discovery is performed by independent participants called searchers. They run algorithms and bots that inspect blockchain state and transactions for profitable opportunities. A searcher may submit transactions or bundles designed to capture an arbitrage, perform a liquidation, back-run a trade, or—in a user-hostile case—sandwich a swap.

Searchers are not the same as validators or block builders. Searchers identify opportunities. Builders assemble blocks and optimize transaction ordering. Validators propose blocks to Ethereum. Modern Ethereum infrastructure can involve private order flow and specialized block-building systems, so the old mental model of “a miner watches the public mempool and reorders everything” is incomplete.

Why your DEX swap can create an MEV opportunity

Suppose you submit a market-style swap that buys TOKEN with ETH from an automated market maker. Your trade itself changes the pool's reserves and therefore its price. If the trade is large relative to available liquidity, that price movement can be meaningful.

If information about the pending transaction is publicly observable, a searcher can simulate what will happen if your swap executes. The bot is not guessing blindly: on-chain state and smart-contract behavior make many outcomes computationally predictable. When the expected profit exceeds transaction costs and other risks, the bot may compete to position transactions around yours.

This is where slippage tolerance matters. A swap normally specifies a limit on how much the execution can deteriorate before it reverts. A wide tolerance gives the transaction more room to succeed after the price moves—but it can also leave more economic room for adverse execution. Uniswap's current support documentation likewise warns that setting slippage too high can result in receiving fewer tokens than expected, while setting it too low can cause a transaction to fail. See Uniswap's slippage documentation.

Sandwich attacks: the MEV pattern swap users should recognize

A sandwich attack surrounds a victim's swap with two attacker transactions. In a simplified example, imagine you are buying a token from an AMM pool:

1. Your buy is submitted and becomes observable while pending.
2. A searcher detects that your trade is likely to move the token price upward.
3. The searcher buys first, moving the pool price against you.
4. Your swap executes at the now-worse price, provided the result remains inside your permitted limits.
5. The searcher sells after your transaction and attempts to capture the price movement as profit.

Uniswap describes this same front-run/user-swap/back-run structure in its official sandwich-attack explanation. Ethereum's documentation also identifies sandwich trading as a common form of MEV extraction.

The key point is that the bot's profit is connected to worse execution for the sandwiched trader. That makes sandwiching different from some other forms of MEV whose effects can be neutral or even useful to markets.

Not all MEV makes your swap worse

DEX arbitrage is the clearest counterexample. If the same asset trades at different prices across two pools or exchanges, a searcher can buy where it is cheaper and sell where it is more expensive. This captures MEV, but it also pushes prices back toward alignment. Ethereum's documentation notes that arbitrage helps DEX users obtain more accurate token prices.

Liquidation MEV is another protocol-level mechanism. Lending systems can reward actors that rapidly liquidate positions whose collateral falls below required thresholds. Searchers compete for those rewards, helping lending protocols enforce their solvency rules.

Back-running can also capture value from the state change created by another transaction without necessarily making that transaction execute worse. The important distinction is therefore not “MEV versus no MEV,” but whether a particular extraction strategy imposes a negative externality on the user.

Price impact is not the same as MEV or slippage

This distinction prevents a lot of confusion. Price impact is the price change caused by your own trade relative to the available liquidity. A large order in a shallow pool can have substantial price impact even when no searcher touches it. Price slippage is the difference between the expected swap result and the result actually received. Uniswap explicitly distinguishes the two in its price impact versus price slippage documentation.

MEV can add another layer. A sandwich searcher may intentionally move the pool price before your swap, worsening execution within the constraints your transaction allows. But if you trade a large amount against thin liquidity and receive a poor quote before submitting anything, that is primarily a liquidity and price-impact problem, not evidence of a sandwich attack.

How the modern MEV pipeline works

Ethereum's post-Merge block-production market is more specialized than the simple public-mempool story suggests. Searchers can discover opportunities and submit bundles; specialized builders can assemble blocks; relays can mediate between builders and validators; and validators ultimately propose blocks. Ethereum documents MEV-Boost as an implementation designed for this proposer-builder market.

Flashbots' documentation separately describes tools for searchers, validators, builders, relayers, and Ethereum users. Flashbots Protect, for example, is designed to keep eligible transactions away from public-mempool front-running and supports MEV-related protections.

This evolution matters because “my transaction was not broadcast publicly” can materially change the attack surface. It does not mean that every private transaction system offers identical guarantees. Protection depends on the wallet, RPC, chain, route, protocol, and exact transaction path being used.

Practical ways to reduce MEV exposure when swapping

Use a wallet or interface with verified swap protection

Private transaction submission can prevent a swap from being exposed in the public mempool where generalized front-runners can see it. As one concrete example, Uniswap states that swap protection in Uniswap Wallet sends Ethereum Mainnet swaps to a private transaction pool and uses Flashbots Protect to defend against sandwich attacks and front-running. The feature's scope is important: do not assume the same protection applies to every network, wallet, or DEX. Check the current product documentation before relying on it. See Uniswap's swap-protection documentation.

Do not solve every failed swap by dramatically widening slippage

If a transaction fails because the price moved beyond your tolerance, increasing slippage can make execution more likely. But an unnecessarily wide limit can also authorize a much worse result. Choose a tolerance appropriate to the asset, liquidity, volatility, and route rather than treating a large percentage as a universal fix.

Pay attention to liquidity and trade size

Uniswap notes that higher-liquidity pools generally produce smaller price impact, while lower-liquidity pools can produce larger impact. A trade that is tiny relative to deep liquidity presents a different economic opportunity from a trade that materially moves a shallow pool. If the quoted price impact is already uncomfortable, reducing the order size or reconsidering the route can be more sensible than merely raising slippage.

Compare the quote, minimum received, and final execution

Before signing, inspect the expected output, minimum received, route, price impact, fees, and network. After confirmation, compare the actual token amounts with the pre-trade expectations. A block explorer can show transaction ordering, but diagnosing a sandwich reliably may require examining the surrounding transactions and pool-state changes rather than simply noticing that the final price was disappointing.

A concrete example

Assume a trader wants to swap 20 ETH for a relatively illiquid token. The quote already indicates meaningful price impact. The trader chooses a generous slippage tolerance because they want the transaction to succeed.

A searcher sees the pending trade and determines that buying the token immediately before it would push the AMM price higher while still leaving the trader's output above the transaction's minimum. The searcher buys first. The trader's 20 ETH swap then executes and receives fewer tokens than it would have without that preceding transaction. The searcher sells after the trader, attempting to realize the difference.

The numbers will vary with pool design, liquidity, gas, competing searchers, routing, and block construction. There is no universal percentage of a swap that bots can extract. Any article or tool claiming a fixed MEV loss for every trade would be oversimplifying the mechanics.

What has changed—and what has not

The durable part of MEV is the economic incentive: whenever transaction ordering or inclusion can change who receives value, sophisticated actors will compete for that value. What has evolved is the infrastructure around that competition. Ethereum now has a mature proposer-builder ecosystem, private transaction channels, and user-facing protection mechanisms. Layer-2 networks also have their own sequencing and MEV designs, so conclusions drawn from Ethereum Mainnet cannot automatically be copied to every rollup.

As of the official Ethereum documentation updated February 26, 2026, the longer-term effects of scaling and changing proposer mechanisms on MEV are still described as areas with uncertainty. That is a useful boundary: the existence of MEV is well established, but the future distribution and exact forms of MEV across evolving execution environments should not be presented as settled.

Bottom line for swap users

MEV is not synonymous with theft, bots, or bad execution. It is a broad category of value created by control over transaction inclusion and ordering. Arbitrage and liquidations can make decentralized markets function more efficiently, while sandwich attacks can directly worsen a trader's execution.

For everyday swaps, focus on the parts you can control: use reputable interfaces with documented transaction protection when available, understand the scope of that protection, avoid unnecessarily loose slippage, check price impact and liquidity before signing, and distinguish a poor quote from an actual ordering-based attack. Searchers will continue to compete for extractable value; your goal is to avoid making your swap an easy source of it.