What Is MEV? A Developer's Plain Explainer
You submit a swap at a good price, it confirms, and you got less than you expected — even though the transaction "succeeded." You didn't do anything wrong. You just met MEV. It's one of the most talked-about and least-understood forces in crypto, and once you see how it works, a lot of confusing on-chain behavior suddenly makes sense.
What MEV actually stands for
MEV = Maximal Extractable Value. (It originally stood for Miner Extractable Value on proof-of-work Ethereum; post-Merge the extractors are validators and specialized actors, so the "M" was generalized to Maximal.)
The plain definition: the extra value that can be captured by choosing the order, inclusion, or exclusion of transactions in a block — beyond the normal block reward and gas fees.
Here's the key insight. A block is an ordered list of transactions, and whoever builds the block decides that order. On Ethereum, transactions are picked from a public mempool where everyone can see everyone else's pending transactions before they're mined. If the order of transactions affects who profits — and in DeFi it constantly does — then the power to order them is worth money. MEV is the value of that power.
Why ordering is worth money
Almost all MEV comes from DeFi, because prices on a DEX move as trades execute. A few canonical examples:
Arbitrage (mostly benign). ETH is $3,000 on one DEX and $3,010 on another. A bot buys low on the first and sells high on the second in the same block, pocketing the spread. This is good MEV in a sense — it keeps prices aligned across venues. It just needs to be ordered correctly to work.
Liquidations (benign-ish). A lending position becomes undercollateralized. Whoever's transaction lands first gets to liquidate it and claim the bonus. Bots race to be that transaction. This keeps lending protocols solvent — it's necessary work — but it's still a race decided by ordering.
Front-running (harmful). A bot sees your large pending swap in the mempool, realizes it will push the price up, and inserts its own buy ahead of yours (by paying a higher tip). It buys cheap, your trade pushes the price, and the bot is now holding tokens that just went up.
Sandwiching (harmful, the one that gets you). The nastiest common form. A bot sees your swap and wraps it:
- Front-run: bot buys the token right before you, pushing the price up.
- Your trade: executes at that inflated price (you get fewer tokens — this is the "slippage" you didn't expect).
- Back-run: bot immediately sells into the price your trade created, profiting.
You paid more than the market price, and the difference went to the bot. Your transaction still shows status: success — it just filled at the bad end of your slippage tolerance.
Back-running (neutral). Landing a transaction immediately after a known one — e.g., arbitraging the price a big swap just moved. Less predatory than front-running, but still an ordering game.
The supply chain that extracts it
Modern Ethereum MEV flows through a pipeline (this is PBS — proposer/builder separation, and the Flashbots-style infrastructure around it):
| Role | What they do |
|---|---|
| Searchers | Run bots that scan the mempool for MEV opportunities and craft bundles of transactions to capture them |
| Builders | Assemble full blocks from bundles + regular transactions, ordered to maximize value |
| Relays | Pass built blocks to validators without revealing contents until chosen |
| Validators/Proposers | Choose the most profitable block to propose — earning a cut of the MEV |
The upshot: extracting MEV is a competitive, specialized industry, and a share of what's extracted flows back to validators — which is why they'll happily include a searcher's carefully-ordered bundle.
Why the public mempool is the enabler
The root cause of harmful MEV is visibility: the public mempool broadcasts your intent to the whole world before it's final. A searcher's bot sees your swap sitting in the mempool, simulates its price impact, and reacts — all before your transaction is mined. No public mempool, no front-running target.
This is also why L2s have a different MEV profile. Most rollups route transactions through a single sequencer rather than a public gossiped mempool, so third-party front-running is largely absent — though you're now trusting the sequencer's ordering instead. Different trust model, different exposure.
What you can actually do about it
If you're building or trading, you're not helpless:
- Set tight slippage. Sandwiching only works within your slippage tolerance. A 0.5% limit caps how much a bot can extract; a 50% limit is an open invitation. This is your single biggest lever.
- Use a private mempool / protected RPC. Endpoints like Flashbots Protect (and similar MEV-protection RPCs) submit your transaction directly to builders, bypassing the public mempool so searchers never see it pending. This is why DEX aggregators advertise "MEV protection."
- Use MEV-aware aggregators. 1inch, CoW Swap, and others route orders to minimize extractable value (batch auctions, private flow, RFQ).
- Split large trades. A huge swap is a fat target; breaking it up reduces the price impact any single sandwich can exploit.
- Mind the chain. On a single-sequencer L2, public-mempool front-running is mostly a non-issue — factor that into where you transact.
Is all MEV bad?
No — and this trips people up. Arbitrage and liquidations are necessary functions that happen to be MEV: they keep prices consistent and lending markets solvent, and someone has to be paid to do them. The harmful subset is the predatory ordering — front-running and sandwiching — that extracts value from ordinary users who simply broadcast a transaction. The ecosystem's response (PBS, private order flow, batch auctions, MEV-share rebates) is largely about redistributing or minimizing that harmful slice while keeping the useful part.
The short version
MEV is the profit available from controlling transaction order within a block. It exists because DeFi prices move as trades execute and the public mempool reveals your intent before it's final. Benign MEV (arbitrage, liquidations) keeps markets healthy; harmful MEV (front-running, sandwiching) skims value from regular swaps within their slippage tolerance. Protect yourself with tight slippage and a private/protected RPC, and remember that single-sequencer L2s change the exposure entirely.
Whether you're building MEV-aware infrastructure or just need reliable transaction submission, it starts with a solid endpoint. A flat-rate Ethereum RPC endpoint gives you HTTP + WebSocket access across dozens of chains under one key. Grab a free key and point your app at:
https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY
Related posts
- Mempool 101: How Pending Transactions Work
You send a transaction and it just says 'pending' — where does it actually go? A plain-English tour of the mempool: how transactions wait, why fees and nonces decide their fate, how to watch them, and how to unstick one.
- Full Node vs Archive Node: What's the Difference (and Which Do You Need)?
Most developers either overpay for an archive node they don't need or hit a wall on a full node that can't answer their query. The difference comes down to one thing — historical state — and here's the simple test for which one your app actually requires.
- The Cheapest Way to Run an Ethereum Archive Node in 2026
What an Ethereum archive node actually costs today — hardware, sync time, bandwidth, hosted options — and the threshold where renting one beats running it yourself.