What is Maximal Extractable Value (MEV)?

Maximal extractable value (MEV) is the value available from choosing which transactions enter a block and in what order, beyond ordinary block rewards and transaction fees. Ethereum’s documentation describes how this creates opportunities for arbitrage and liquidations, but also strategies that worsen other users’ trades.

For a separate breakdown of fees, price impact and slippage tolerance, see The Defiant's swap-cost guide.

Who sees a transaction before it reaches a block?

Publicly broadcast Ethereum transactions enter a public pool of pending transactions, where MEV searchers can inspect them before block inclusion. Not every transaction takes that route: Flashbots Protect, for example, accepts private submissions that are hidden from the public mempool.

Public flow: wallet → public RPC node → public transaction pool → block inclusion. Private flow through Protect: wallet → Protect RPC → receiving block builder(s) → block inclusion. Private submission changes who can see a pending order, not the swap's minimum-output condition.

Arbitrage, liquidations and sandwiches

Searchers identify profitable opportunities and submit transactions or bundles seeking execution. Builders assemble blocks; validators propose them. A searcher can buy a token on one decentralized exchange and sell it on another at a higher price, or compete to submit a profitable liquidation. Finding an opportunity does not itself grant control over the next block.

Other tactics include front-running—slipping ahead of your transaction; sandwich attacks, where they buy just before you and sell right after your trade goes through; even “generalized front-running,” where bots copy profitable patterns in your trades and beat you to execution.

A sandwich can worsen execution even when a swap satisfies its minimum output. Consider a hypothetical exact-input swap, ignoring fees and gas and holding other conditions constant. At the pool's pre-trade spot price, the input would buy 1,000 tokens. Assume the trader's own price impact reduces the no-attack quote and output to 990 tokens, and the trader sets a minimum of 980. With a sandwich, assume the attacker's buy moves the price first, the same input receives only 982 tokens, and the attacker sells afterward. Both 990 and 982 exceed the same minimum, but adversarial ordering has cost the trader eight tokens relative to the no-attack baseline. These are illustrative assumptions, not a measured trade.

For a swap enforcing this minimum, an output below 980 would trigger a revert, undoing the swap. The minimum is an execution floor, not proof that no sandwich occurred or that the best available price was obtained.

What execution controls do—and do not—protect

Private routing limits public visibility; it does not remove the need to check execution controls. Flashbots Protect's settings guide documents which builders receive transactions and which information is shared with searchers. Sending a transaction to a builder requires trusting it not to front-run or disclose the order.

Private routing and block construction are different

Proposer-builder separation (PBS) is distinct from private routing. It separates block construction from block proposal; it does not itself hide a user's pending swap from the public mempool or enforce a trader's execution floor. Private submission concerns how an order reaches builders, while PBS concerns how a built block reaches the proposer.

Correction (2026-11-01): The article incorrectly stated that every transaction enters the public mempool; private submission routes can bypass it.