The section on the homepage covers the mechanics and three principles. The real question is narrower: for this wallet, this tool, what do I actually click? This page answers that by chain and by tool, and states what each protection covers and what it costs.
Checked in October 2026. Tool features and switch locations change — go by each provider's own documentation.
Three layers, and your tool decides which you get
It gets much clearer if you separate protection by which step it acts on:
| Layer | What it is | What it does | What it costs |
|---|---|---|---|
| One | Keep the transaction unseen (private RPC or private pool) | The most direct. A sandwich has to see your transaction before it can wrap it | One more intermediary to trust; possibly a few seconds slower |
| Two | Make ordering stop mattering (batch auctions, signed intents) | Being seen stops helping, because fills are not ordered by arrival | Not every pair has liquidity; adoption is limited |
| Three | Cap what can be taken (tighter slippage) | Lowers how much a single trade can lose | Too tight and ordinary volatility fails the swap |
Layer one is both the most effective and the easiest to do, and it does not depend on which wallet you use — so it comes before any tool-specific advice below.
Is Uniswap V4 easier to defend than V2?
Short answer: the protocol allows it, but "V4" does not mean "protected".
V2 is a plain AMM with no MEV protection at the protocol level; trades execute in arrival order. V4 introduced hooks, and a pool can attach custom logic — including a MEV protection hook.
The idea behind such a hook is to break the atomic same-block execution that a sandwich depends on: delay the swap into a later block, so the attacker cannot complete "buy ahead, your fill, sell after" inside one block. Open-source implementations exist, including AntiSandwich, AntiJIT and MEVRebate.
But three practical constraints matter more than the mechanism:
- The hook is chosen by whoever deploys the pool. A user can only pick between a pool that has protection and one that does not — you cannot add it yourself.
- Most V4 volume does not run through hooked pools. As of June 2026, hooked pools accounted for roughly 15–20% of volume — meaning most V4 trades sit in pools with no extra protection, exactly like V2.
- V4 moves the security model from protocol-level to pool-level. Using an unfamiliar hook pool means trusting that hook's developer with your funds. And once bound, a hook cannot be swapped out.
So: do not relax because something is on V4. Look at whether that specific pool has protection and who wrote the hook. For most people, whether you are on layer one at all matters far more than V2 versus V4.
The general move: point your wallet at a private RPC
This works regardless of what your wallet offers. MetaMask, Rabby or anything that accepts a custom RPC can do it. Your transaction stops entering the public mempool, so sandwich bots never see it.
Ethereum:
- Flashbots Protect:
https://rpc.flashbots.net/fast— the original and still the most widely used. - MEV Blocker:
https://rpc.mevblocker.io— hides the transaction and also returns a share of the backrun value to you. It offers several endpoints with different priorities (speed, no reverts, maximum privacy, maximum rebates); pick by what you need.
BNB Chain:
- PancakeSwap:
https://bscrpc.pancakeswap.finance - Merkle:
https://bsc.merkle.io - 48 Club:
https://rpc-bsc.48.club
These three are the free private RPCs BNB Chain itself lists in its MEV protection guidance. Their documentation puts average confirmation at about 4–5 seconds, varying with network conditions.
Check your tool: do the step that applies to you
| Tool | How to turn it on | Scope and limits |
|---|---|---|
| Binance Web3 Wallet | On by default; there is a "MEV Protection" toggle in the trade screen | If you are sandwiched with it on, you can claim compensation; turn it off and the loss is yours |
| OKX Web3 Wallet | Swap → "More" → "MEV Protection" | Covers Ethereum single-chain swaps only |
| Trust Wallet | Swap → settings (top right) → turn on MEV Protection | On by default |
| TokenPocket / SafePal / Math Wallet | Turn it on in each app's swap settings | All appear on BNB Chain's official list |
| GMGN | Turn on the anti-MEV mode in the trade parameters | Supports Ethereum, BSC and six more chains; sandwiched with it on, you can claim compensation |
| MetaMask and others | Switch the RPC to a private endpoint | See the endpoint list above |
Binance Web3 Wallet: on by default, and do not rush to turn it off
Protection is on by default here, and a sandwich with it on can be claimed back — with it off, the loss is yours. So "my trades keep failing, let me disable it" is usually the wrong instinct.
Read the error first; most failures do not call for turning it off:
- "Slippage too low" or a volatility warning → widen slippage slightly, rather than disabling protection.
- "Priority fee too low" or a timeout → a private channel can need a slightly higher fee; raise the priority fee.
- "RPC service failure" → this is the one case where you should switch it off temporarily: the protection service itself is down, so finish the trade in normal mode.
OKX Web3 Wallet: manual, and Ethereum-only
Open any swap, tap "More" → "MEV Protection". Once on, the transaction goes to a trusted private pool instead of the regular one, so its ordering cannot be changed.
Mind the scope: it covers Ethereum single-chain swaps only. Cross-chain routes, and transactions you sign yourself inside a DApp, are not covered by this switch.
GMGN: the anti-MEV mode is free, and it is the condition for a refund
Turn on the anti-MEV mode in the trade parameters and the transaction is submitted to a private pool for inclusion — third parties cannot see your pending order. GMGN lists it as a feature with no extra fee.
GMGN has also stated that if you are sandwiched with the mode on, you can submit the transaction hash and claim compensation. So having it on has value beyond the protection itself — it is also the precondition for a refund.
One piece of practical advice from GMGN's co-founder: do not widen slippage just to raise your success rate. Short-term volatility on these tokens is usually not that large, the extra room buys little success, and it is exactly the room a sandwich extracts from.
If your wallet has no built-in protection
Use the private RPC above. It is the broadest option and does not depend on the wallet brand.
Five things people get wrong
- "Protection is on, so I am safe." — A wallet's built-in protection usually covers swaps made inside that wallet. A transaction you sign yourself on a DApp page is outside it. This is the single most overestimated point.
- "V4 is safer than V2." — See section B. Most V4 volume runs through pools with no hook at all.
- "Tighter slippage is always safer." — Slippage does cap what can be extracted, but set it too tight and ordinary volatility fails the swap. In Binance's own troubleshooting guidance, slippage set too low is a leading cause of failed transactions. It is a trade-off, not a dial to minimise.
- "Turning protection off is no big deal." — Both Binance and GMGN let you claim compensation for a sandwich that happened while protection was on. Turn it off and that claim no longer exists.
- "Solana can be protected the same way." — Solana has no public mempool layer, so there is nothing to hide a transaction from. Its sandwich pattern differs from Ethereum's, and the defences do not transfer.
One honest closing note: no setting makes you immune. Every item above shrinks part of the attack surface. The real test is not "do I have protection on", but "is attacking me now more expensive than what is on me to take".