MEV for Non-Quants: Sandwich Attacks, PBS, Private RPCs, and Practical Ways to Reduce Losses

What is MEV in plain English?

MEV stands for Maximal Extractable Value. It refers to the profit that can be extracted by deciding how transactions are ordered, included, or excluded inside a block. A blockchain block is not just a neutral list of transactions. Someone builds that list. If that builder can see pending transactions, simulate their effects, and choose the order, they may discover profitable opportunities.

A simple way to think about MEV is queue control. Imagine a ticket line where the person arranging the line can move people around after seeing what everyone wants to buy. If your purchase changes the price, the line arranger or a fast trader can step in before you, benefit from your action, then exit after you. In DeFi, that can happen through automated bots, searchers, builders, relays, and validators.

The important point for users is not the acronym. The important point is that a transaction visible before finalization can be copied, simulated, priced, routed around, or placed between other transactions. If your swap allows too much slippage, your transaction can become a profit opportunity for someone else.

Where MEV comes from

MEV is not one attack. It is a group of profit opportunities created by transparent transactions, predictable smart contract logic, liquidity pool math, oracle updates, liquidations, bridge timing, and block ordering power. Some MEV is neutral or even useful, such as arbitrage that keeps markets aligned. Some is directly harmful to users, such as sandwiches that convert your slippage into bot profit.

AMM swaps and price impact

Automated Market Makers such as Uniswap-style pools price trades using liquidity pool math. A large swap moves the pool price. If your transaction is visible before it confirms, a searcher can calculate whether buying before you and selling after you is profitable.

The core weakness is predictable execution. If the bot can see your trade, estimate how much price impact it creates, and fit its own transactions around yours, the bot can capture value from your slippage tolerance.

Arbitrage and backruns

Arbitrage is MEV when bots profit from price differences between venues. If your trade makes one pool cheaper or more expensive than another pool, a bot may backrun your transaction to close the price gap. Backrunning is not always harmful in the same way as sandwiching because it can restore market efficiency, but it still reveals how quickly bots act around user flow.

Lending liquidations

Lending protocols liquidate borrowers when collateral value falls below required safety thresholds. Liquidators earn incentives for closing risky positions. This is useful for protocol solvency, but brutal for users who run thin health factors. Bots monitor oracle updates, pending transactions, and price moves so they can liquidate faster than humans.

Oracle and keeper timing

Oracles publish price updates. Keepers trigger protocol actions. These updates can create predictable moments where prices change or positions become liquidatable. If bots know when a feed is likely to update, they can prepare actions around that update.

NFT mints and gas wars

During hyped NFT mints, bots compete for limited supply. They may bid high priority fees, route bundles strategically, and capture supply before normal users can react. The result is familiar: failed transactions, high gas, and retail users paying to lose the race.

How sandwich attacks work

A sandwich attack is the MEV pattern most users feel directly. It happens when a bot places one transaction before your trade and another transaction after your trade. Your swap sits in the middle like the filling in a sandwich.

The bot first buys the asset you are about to buy. That pushes the pool price against you. Your swap then executes at a worse price, but still within your slippage setting. After your swap moves the price further, the bot sells back and captures the difference. The wider your slippage and the thinner the pool, the easier this becomes.

Why slippage is the attack budget

Slippage is the maximum price movement you are willing to tolerate before your transaction reverts. Some users increase slippage because they want the transaction to go through. That can be reasonable for volatile or illiquid pairs, but high slippage also creates room for extraction.

If a liquid major pair works with 0.3% to 0.8% slippage, using 5% may be unnecessary and dangerous. The bot does not need to steal all the slippage. It only needs enough room to profit after gas, builder payments, and risk.

Signs you may have been sandwiched

• Your received amount was close to your minimum output even though market price barely moved.
• Your transaction is surrounded by similar buy and sell transactions in the same block.
• The same address or bot contract traded immediately before and after you.
• Your slippage was high relative to pool liquidity.
• The pair was thin, volatile, or recently trending.

What PBS and MEV-Boost changed after Ethereum’s Merge

Before Ethereum’s Merge, miners built and proposed blocks. After the Merge, Ethereum moved to proof of stake. Validators propose blocks, but specialized builders often assemble the actual block contents. This separation is called Proposer-Builder Separation, or PBS.

In the current practical model, builders compete to create valuable blocks. Relays deliver bids. Validators choose the best block bid. MEV-Boost is the software stack that made this market more accessible to validators. The result is a more professionalized block-building supply chain.

Why users should care about PBS

PBS matters because it changes who sees orderflow, who builds blocks, and how extraction is organized. It does not remove MEV. In many ways, it makes MEV more efficient. But the same infrastructure that allows professional extraction also enables private and protected orderflow paths that can help users avoid the public mempool.

PBS trade-offs

• Efficiency: specialized builders can extract and route value more efficiently.
• Validator revenue: validators can earn from block bids without running complex search systems themselves.
• Centralization pressure: builder and relay concentration can become a network risk.
• User protection routes: private RPCs and intent systems can bypass public mempool exposure.
• Policy risk: relays and builders may differ in censorship policies, reliability, and inclusion behavior.

How MEV feels for normal users

MEV can sound abstract until it hits a wallet. For retail users, the experience is usually not labeled MEV. It appears as a confusing swap result, an unexpected failure, a liquidation that happened too quickly, or a mint that felt impossible to win.

Bad swap execution

You preview a swap and expect a certain output. By the time the transaction confirms, the output is worse. Some of that may be normal price movement. Some may be pool price impact. Some may be MEV extraction.

Failed transaction with gas loss

A transaction can fail because market conditions changed before it landed, the route became invalid, the slippage tolerance was too tight, or another bot captured the opportunity first. You may still pay gas for the failed attempt.

Liquidation sniping

If your lending health factor is close to liquidation, bots do not wait politely. They monitor collateral prices, mempools, oracle updates, and liquidation profitability. When your position becomes eligible, automation acts faster than a human dashboard refresh.

NFT gas wars

During first-come mints, bots use aggressive fee strategies and automation to secure supply. Retail users often end up paying for failed attempts. Better mint designs use allowlists, batch auctions, randomization, commit-reveal systems, or other fairness controls.

Mitigation that actually works

You cannot turn off MEV at the network level. But you can reduce the amount of extractable value you expose. The best user defenses fall into three groups: private orderflow, MEV-aware apps, and safer transaction settings.

1. Use private or protected RPCs

A public RPC sends your transaction into the public mempool, where bots can see and simulate it before inclusion. A private or protected RPC routes your transaction through a private path so it is not broadcast openly in the same way.

Private RPCs are not magic. Inclusion can differ from normal public RPC behavior. Some providers may reject toxic orderflow, have delays, or experience outages. Keep a fallback RPC and read provider policies before relying on one route for critical transactions.

2. Use intents, RFQ, and batch auction systems

Instead of posting a raw AMM swap directly into a public mempool, intent and RFQ systems let solvers, fillers, or market makers compete to satisfy your desired outcome. This can reduce sandwich risk because your order is not simply exposed as a naive AMM transaction.

3. Shape the transaction you send

Even without changing apps, you can reduce MEV leakage by sending better transactions. The goal is to make the trade less attractive to exploit.

• Lower slippage: for liquid majors, 0.3% to 1% may be enough. Avoid 5% or 10% as a default.
• Use short deadlines: a transaction that can execute far later can become dangerous in volatile conditions.
• Split large trades: avoid moving thin pools with one obvious transaction.
• Use aggregators: compare routes instead of relying on a single pool.
• Use permit carefully: Permit2 and typed approvals can reduce approval friction, but you still need to read spender, amount, and expiry.
• Revoke old approvals: use reputable approval tools such as Revoke.cash.

Step-by-step recipes for normal users

The exact interface may change by wallet, but the principles are stable: use trusted routes, reduce public mempool exposure, and control transaction parameters instead of blindly clicking through.

Recipe 1: Route through CoW Swap

1. Open cow.fi from a bookmark or manually typed URL.
2. Connect your wallet and select the token pair.
3. Review the amount, quote, network, and order details.
4. Set realistic slippage.
5. Submit the order and let solvers compete to settle it.
6. Review the final executed price and keep a record if the trade size was meaningful.

Recipe 2: Add a protected RPC to MetaMask

In MetaMask, go to Settings, then Networks, then Add network manually. Add the protected RPC endpoint from the official provider page. Do not copy RPC endpoints from random tweets, Discord messages, Telegram posts, or unofficial guides.

Recipe 3: Use 1inch Fusion or UniswapX for larger swaps

1. Open the official 1inch or Uniswap interface.
2. Check whether Fusion or UniswapX is enabled and supported for your chain and token pair.
3. Review the effective quote and route.
4. Read any signature or permit prompt carefully.
5. Do not sign unlimited approvals unless you understand the spender and risk.
6. Compare final execution against other reputable aggregators for large trades.

Recipe 4: Sensible defaults for everyday swaps

DeFi habits that quietly save money

Most MEV protection is not dramatic. It is basic transaction hygiene repeated consistently. Better routes, better settings, and better timing can save more than chasing every tiny gas optimization.

Liquidity and timing

• Trade when pool liquidity is deep and volatility is lower.
• Avoid forcing large trades through thin pools during major news or market stress.
• Use aggregators to compare routes and price impact.
• For larger trades, split across time or use RFQ/intent systems.
• Check Dune dashboards or DEX analytics to understand pool depth and activity.

Security and approvals

• Use Permit2 or per-trade approvals when appropriate, but read typed data carefully.
• Revoke stale token and NFT approvals with reputable tools.
• Do not connect a vault wallet to random swap front ends.
• Use a smaller daily wallet for active DeFi.
• Check spender addresses before approving.

Borrowing and liquidation habits

Lending users should treat liquidation bots as always awake. If your position is near liquidation, do not assume you will have time to react manually. Keep a healthier buffer, especially for volatile collateral.

• Keep a higher health factor than the minimum. For volatile collateral, thin buffers are dangerous.
• Set alerts for health factor, collateral price, and oracle movement.
• Understand the protocol’s liquidation threshold and penalty.
• Know which oracle feed the protocol uses.
• Consider auto-repay or automation tools only after understanding their own contract and key risks.

MEV on L2s: Arbitrum, Optimism, Base, and beyond

MEV does not disappear on Layer 2 networks. It changes shape. Many L2s have sequencers that order transactions before they are posted to Ethereum. Some do not expose a public mempool the same way Ethereum mainnet does. But the core questions remain: who sees your order before it finalizes, who can order it, and what policies govern that ordering?

Sequencer role

On many L2s, the sequencer has a central role in transaction ordering. That can improve user experience and reduce some mempool behaviors, but it also introduces trust assumptions. Users should understand the L2’s sequencer model, roadmap to decentralization, and MEV policy.

The same user habits still help

• Use reputable front ends.
• Compare aggregator routes.
• Set realistic slippage.
• Use intent or RFQ routes where supported.
• Avoid large market-moving trades in thin pools.
• Understand bridge and settlement timing.

Useful starting points include Arbitrum Docs, Optimism Docs, and Base Docs.

Builders’ corner: shipping MEV-aware products

Wallets, DEXs, aggregators, bridges, games, and DeFi front ends should not push MEV responsibility entirely onto users. Good products make safe routing the default, not a hidden setting.

Controls builders should consider

• Private relay routing: offer protected transaction routing by default where suitable.
• Intent and RFQ routing: use solver or market maker routes for larger trades.
• Sandwichability warnings: warn users when slippage and price impact make a trade highly exploitable.
• Pre-trade simulation: show expected output, price impact, route, gas, and failure risk.
• Post-trade receipts: show quoted output versus received output and explain differences.
• Safer approvals: support exact approvals, Permit2 where appropriate, and clear revoke links.
• Fallback behavior: explain what happens if a private RPC does not include the transaction quickly.

References for implementers

• Flashbots MEV-Boost
• Flashbots Protect RPC
• CoW Protocol Docs
• 1inch Fusion
• UniswapX
• Ethereum.org MEV

Common MEV mistakes users make

Most user-level MEV losses come from predictable mistakes. None of these mistakes require advanced math. They are execution habits.

Mistake 1: using high slippage because a trade failed once

Raising slippage can help a transaction execute, but it can also increase extractable value. If the trade keeps failing, ask why. The pair may be too illiquid, the route may be poor, or the token may have tax or transfer logic.

Mistake 2: using public mempool routes for every trade

Public mempool exposure is not always fatal, but it is avoidable for many sensitive swaps. Protected RPCs, batch auctions, intents, and RFQ systems exist because public mempool execution can be exploited.

Mistake 3: trading from a vault wallet

Your vault wallet should not be your daily DeFi wallet. Active trading requires approvals, routing, signatures, and experimentation. Keep meaningful funds separate from active swap flow.

Mistake 4: forgetting approvals

MEV protection and approval hygiene overlap because both are about transaction discipline. If you approve a router or Permit2 spender, know what you approved and revoke when the permission is no longer needed.

Mistake 5: running thin health factors

A lending dashboard can look safe until volatility hits. Liquidation bots do not sleep. If your position depends on reacting faster than automated bots, the position is poorly designed.

Quick check before your next swap

Before signing a meaningful swap, run this quick check. If you cannot answer these questions, slow down.

References and further reading

• Ethereum.org MEV overview
• Flashbots research and writings
• Flashbots MEV-Boost overview
• Flashbots Protect RPC quick start
• MEV Blocker RPC
• bloXroute Docs
• CoW Swap and CoW Protocol Docs
• 1inch Fusion explainer
• UniswapX overview
• Uniswap Permit2 overview
• Revoke.cash
• EIP-1559
• Chainlink Data Feeds
• Aave Liquidations FAQ
• Compound Docs
• Arbitrum Docs
• Optimism Docs
• Base Docs
• Dune Analytics dashboards
• Taichi Network
• Matcha and 0x Docs

Verdict: MEV defense is transaction discipline

MEV is not only a technical debate between validators, builders, searchers, and protocol researchers. It affects normal users through worse swap execution, failed transactions, liquidation sniping, and gas wars. The public mempool makes pending transactions visible. AMM math makes price impact predictable. Bots turn those conditions into profit.

The practical defense is not to become a quant. The practical defense is to send better orderflow. Use private or protected RPCs when appropriate. Prefer batch auctions, intents, RFQ systems, and reputable aggregators for meaningful swaps. Keep slippage realistic. Use short deadlines. Split large trades. Avoid trading from vault wallets. Revoke approvals you no longer need.

MEV will continue evolving across Ethereum, L2s, appchains, and new intent markets. The safest user habit is simple: do not expose more information, slippage, permission, or liquidity impact than necessary.

FAQs

Final reminder: MEV protection starts before you click swap. Check the route, use protected orderflow when needed, keep slippage realistic, avoid thin pools, review approvals, and never expose your vault wallet to routine DeFi experiments. Check first, then decide.