Use Mempool Data to Avoid Sandwich Attacks

By DeFi Intel Research · Reviewed 2026-07-02 · 8 min read · beginner

Mempool sandwich avoidance is the practice of shielding your DeFi swaps from frontrunning and backrunning bots that use public transaction pools. When you submit a trade on Ethereum or other EVM chains, it sits in the mempool — a waiting room visible to everyone — until a miner includes it. Malicious bots monitor this pool, detect profitable swaps, and execute a “sandwich”: buying just before you (driving up the price) and selling right after (at your inflated price), pocketing the difference at your expense.

For beginners, this feels like invisible theft. But with the right tools and settings, you can keep your trades private. This guide covers mempool data mechanics, real-world protection methods using Flashbots, MEV Blocker, CoW Swap, and RPC tricks, plus a step-by-step plan to avoid being sandwiched. No live prices or TVL — just durable strategies.

How Attackers Use Mempool Data to Sandwich You

A sandwich attack requires three transactions in order: a frontrun (buy), your victim transaction (swap), and a backrun (sell). The attacker’s bot continuously scans the mempool for pending swaps that will move the price. When it sees your large buy order on a DEX like Uniswap, it calculates the expected price impact. If the profit potential exceeds gas costs, the bot issues a buy with a higher gas price to get included first, then posts a sell after your trade.

Concrete example: You want to swap 10 ETH for USDC at 1 ETH = 2000 USDC. The current pool has 100 ETH and 200,000 USDC. A 10 ETH buy will drop the price to ~1960 USDC per ETH. The bot frontruns with 5 ETH, pushing the price to 1980, then your 10 ETH buy executes at ~1940, then the bot sells its 5 ETH for ~1940, netting profit from the price difference. Your final price is far worse than expected.

The mempool makes this possible because it broadcasts pending transactions in plain text. Attackers use node RPC methods like eth_getBlockByNumber or subscribe to pending transactions to see every trade before it’s mined.

What Is Mempool Sandwich Avoidance?

Mempool sandwich avoidance refers to any technique that either hides your transaction from the public mempool or makes it economically unattractive to attack. The core idea: if bots cannot see your transaction details (amount, slippage, deadline), they cannot frontrun it. Alternatively, if your trade is structured to minimize profit (tight slippage, low deadline), bots will skip it.

Protection methods fall into three categories: private mempools (Flashbots Protect, MEV Blocker, Eden), signed order books (CoW Swap, 1inch Fusion), and parameter hardening (slippage limits, deadline windows). Each has trade-offs in cost, speed, and ease.

A common beginner mistake: assuming that using a hardware wallet or a contract wallet already protects you. It does not — sandwich attacks target the transaction itself, not the ownership of assets.

Private Mempools: Your First Line of Defense

Private mempools are custom transaction channels that bypass the public pool and go directly to miners or validators. The most popular is Flashbots Protect (Ethereum mainnet) and its MEV-Boost relay network. When you send a transaction via Flashbots’ RPC endpoint, it is only seen by Flashbots searchers and miners who agree to include it without frontrunning.

How to use it: Change your wallet’s RPC URL to https://rpc.flashbots.net (or use the Flashbots Protect app). After connecting, every transaction you send goes through the private relay. It may take slightly longer to confirm (extra ~1 block), but the trade is safe from sandwich bots.

Other options: MEV Blocker (by CoW DAO) offers a private RPC with refunds if any MEV is extracted from your transaction. Eden Network provides a priority fee market but requires staking EDEN tokens for full protection. For beginners, Flashbots Protect is free and simple to set up.

Tip: Combine Flashbots Protect with a dedicated hardware wallet (Ledger, Trezor) for both physical security and MEV protection.

Using RPC Methods for Private Transactions

Advanced users can send transactions directly to miners using JSON-RPC methods like eth_sendPrivateTransaction (Flashbots) or eth_sendRawTransactionConditional (Eden). These methods allow you to specify a target miner, a maximum block number, and a bundle structure that includes your transaction with no dependencies.

Example: Using ethers.js in a script, you can create a private transaction and call flashbots.sendTransaction(signedTx). This sends your swap directly to Flashbots miners. The fee is still paid in gas, but there is no extra premium beyond the gas price you set.

Most retail users won’t need to code; MetaMask and wallets like Frame integrate Flashbots RPC. However, understanding the RPC method helps you debug issues. If your private transaction fails, check the block number condition — if the block passes, the transaction is dropped.

This method is also used by MEV searchers themselves to submit bundles of multiple transactions (e.g., arbitrage, liquidations) without public exposure.

Slippage and Deadline Settings: Simple but Effective

Even without private mempools, you can reduce sandwich risk by tightening slippage and deadline in your swap. Slippage is the maximum percentage the execution price can differ from the quoted price. If you set it to 0.5%, a sandwich bot that would need 2% price deviation cannot profitably attack you. Deadline is the number of blocks after which the swap expires. A short deadline (e.g., 10 blocks, ~2 minutes) prevents attackers from waiting for a favorable block position.

Most DEXs (Uniswap, SushiSwap, PancakeSwap) let you set these in the UI. Set slippage to 0.5% or lower for stable pair swaps (e.g., USDC/DAI). For volatile pairs, you may need 1–2% but never exceed 3% unless you accept high sandwich risk.

Concrete example: On Uniswap, go to the swap settings, set “Slippage tolerance” to 0.5% and “Transaction deadline” to 10 minutes (or 30 blocks). This makes it nearly impossible for a bot to frontrun and backrun profitably because the price would need to move more than 0.5% — which your transaction would reject.

Downside: if the market moves rapidly, your transaction may fail (slippage exceeded). You will need to retry, but that’s better than being sandwiched.

MEV Protection in Major DeFi Protocols

Several DeFi aggregators and DEXs now natively protect users from sandwiches. CoW Swap uses a batch auction mechanism where trades are settled by solvers who compete to find the best price. Since trades are not submitted individually to the mempool, but as signed orders, they are invisible to bots. CoW Swap also offers “MEV protection” free for limit orders.

1inch Fusion mode, ParaSwap with Augustus RFQ, and DODO Private Pool use similar signed order books or private RFQ systems. These protocols handle the complexity for you — you just place the order and wait for a solver to fill it.

For direct Uniswap V3 positions, you can use the UniV3 Staker (for liquidity) but for swaps, consider using the Uniswap X (beta) or router contracts with MEV protection enabled.

Comparison: Using CoW Swap or 1inch Fusion is the easiest for beginners — no RPC changes needed, just connect wallet and trade. However, execution may be slower (sometimes 5–15 blocks) because solvers need to find a match.

Comparison Table: Private Mempool vs. Slippage vs. Protected DEX

Step-by-Step Guide to Avoiding Sandwich Attacks

Follow these steps, ordered from easiest to most robust. Start with step 1 and add layers as needed.

1. Set slippage to ≤0.5% and deadline to 10 minutes on every DEX swap.
2. Switch your wallet to a private RPC (Flashbots Protect). In MetaMask: Settings → Networks → Add Network → Use Flashbots RPC.
3. Use a protected DEX aggregator like CoW Swap or 1inch Fusion for large swaps.
4. For advanced protection, send transactions via eth_sendPrivateTransaction with a block limit (e.g., maxBlockNumber = current + 5).
5. Monitor your transactions with mempool explorers (e.g., Etherscan’s pending tx view) to confirm they don’t appear publicly.
6. Use a hardware wallet to secure private keys; this does not directly avoid sandwiches but prevents other attacks.
7. Consider bundling your swap with a small anti-frontrun twist: use a contract that splits the trade into multiple parts automatically (e.g., via Paraswap’s RFQ).

After each swap, check the actual execution price via Tx Receipt (logs) against the quoted price. If you notice consistent slippage above your setting, adjust the deadline or switch to a higher protection method.

Step-by-step

1. Set slippage to 0.5% or lower and deadline to 10 minutes on every DEX swap.
2. Switch your wallet’s RPC to Flashbots Protect (https://rpc.flashbots.net) or MEV Blocker.
3. Use a protected DEX like CoW Swap or 1inch Fusion for swaps over $500.
4. For scripted trades, send transactions using eth_sendPrivateTransaction with a block limit.
5. Verify your transaction does not appear in the public mempool by checking Etherscan pending txs.
6. Use a hardware wallet (Ledger/Trezor) for key security (complements mempool protection).
7. Consider splitting large swaps into smaller chunks to reduce single-trade impact.

Common mistakes to avoid

• Setting slippage too low (e.g., 0.1%) causing constant transaction failures.
• Ignoring deadline setting; leaving default 30–60 minutes gives bots plenty of time.
• Assuming that using a VPN or an incognito browser hides your transaction from the mempool (it does not).
• Using a public RPC (Infura, Alchemy default) while expecting mempool privacy.
• Forgetting to switch RPC back after using Flashbots Protect; other transactions may fail or be delayed.
• Thinking that a small swap (< $100) cannot be sandwiched; bots attack any profitable opportunity, even tiny amounts.

Frequently asked questions

Related reading

• Sandwich Attack
• How To Avoid Address Poisoning Attacks
• How To Avoid MEV Attacks Swaps
• Flash Loan
• Liquidity Pool
• Slippage
• First Crypto Swap Step By Step
• How To Avoid Fake Airdrop Scams