Every swap you submit on a public blockchain sits in a waiting room called the mempool before a validator picks it up. Bots watch that waiting room around the clock. The moment they spot a trade big enough to move a price, they can slip their own orders in front of and behind yours, pocketing the difference and leaving you with a worse fill. That practice is called MEV, short for maximal extractable value, and the tooling to block it has changed more in the past year than in the previous three combined.

This tutorial walks through setting up real MEV protection on Ethereum, Polygon, Base, BNB Chain, and Solana using tools that shipped or updated in 2025 and 2026: Flashbots Protect, Polygon’s Private Mempool, and GetBlock’s MEV-protected RPC endpoints. By the end you’ll have a working Node.js project that routes trades through a private channel, checks slippage before it signs anything, and logs whether a transaction actually avoided the public mempool. No prior MEV experience required, but you should be comfortable running npm commands and editing a JavaScript file.

None of this is theoretical risk you can shrug off. Every DEX swap, every liquidation bot, every arbitrage script competing for block space is a potential target, and the more DeFi volume grows, the more profitable it becomes for someone to run a bot that just watches and waits. Retail traders using a phone wallet and a default slippage setting are the easiest marks, because they broadcast to the public mempool with wide enough tolerance to make an attack worth the gas. Developers shipping a new dApp face the same exposure at a larger scale, since a single unprotected admin transaction or liquidity migration can be an even bigger payday for a bot watching the mempool.

What MEV Bots Actually Do to Your Trades

A sandwich attack is the most common MEV strategy retail traders run into. A bot watches the public mempool, spots your pending swap, then fires a buy order right before yours with a higher gas fee so it lands first. Your trade executes at a worse price because the bot already pushed the pool. The bot then sells immediately after, in the same block, capturing the spread. Front-running and back-running work on the same principle but target different transaction types, like liquidations or arbitrage opportunities rather than swaps.

The fix isn’t complicated in concept: if a bot can’t see your transaction before it’s mined, it can’t sandwich it. That’s exactly what private mempools and protected RPC endpoints do. They route your signed transaction directly to a block builder or a small set of trusted relays instead of broadcasting it to every node on the network. Validators can technically still see it, but the army of copy-trading bots scanning the public mempool never does.

Walk through a concrete example. Say you submit a $10,000 swap on a mid-liquidity pool with the default 1% slippage tolerance most wallets ship with. A sandwich bot spots that transaction sitting in the public mempool within milliseconds, because it’s running a node that mirrors mempool activity in real time. It calculates that your trade will move the price enough to profit from, then submits a buy transaction with a higher gas fee so it lands in the block right before yours. Your swap executes against the now-inflated price, close to your slippage ceiling. The bot’s sell transaction lands immediately after, in the same block, closing the loop. The entire operation takes one block, roughly 12 seconds on Ethereum, and you’d have no idea it happened unless you compared your execution price against the quote you were shown before signing.

Attack TypeHow It WorksPrimary TargetBest Defense
Sandwich attackBot buys before your trade, sells right after in the same blockDEX swaps with visible slippage tolerancePrivate RPC + tight slippage limit
Front-runningBot copies a profitable pending transaction and pays more gas to land firstArbitrage, NFT mints, liquidationsPrivate mempool submission
Back-runningBot executes immediately after a known transaction to capture a price shiftLarge swaps, oracle updatesBundle protection, batch auctions
Time-bandit reorgValidator or miner reorganizes recent blocks to capture missed MEVHigh-value transactions near chain tipMore block confirmations before acting

Prerequisites

You don’t need a large stack to follow this guide, but a few pieces need to be in place first.

  • Node.js 24 (the active LTS line as of mid-2026) and npm installed
  • A code editor and basic comfort with the terminal
  • A MetaMask wallet (or any EIP-1193 wallet) with a small amount of ETH for gas on a testnet or mainnet
  • ethers.js v6.17.0 for the scripting examples (npm i ethers)
  • Hardhat 3.12.0 if you want to follow the deployment-side steps (npm i --save-dev hardhat)
  • A free Flashbots Protect RPC endpoint (no signup required for the basic tier)
  • Optional: a paid GetBlock account if you plan to use its MEV-protected endpoints on Base, BNB Chain, or Solana

Before touching your seed phrase or hardware wallet in any of these scripts, make sure it’s backed up properly. Our guide on seed phrase security and offline backups covers that groundwork if you haven’t done it yet.

Cost-wise, the Ethereum and Polygon tools in this guide don’t charge anything beyond normal gas fees. GetBlock’s MEV-protected endpoints are bundled into its paid shared-node tiers rather than sold separately, so budget for a node provider subscription if Base, BNB Chain, or Solana coverage matters to you. None of these tools require you to move funds into a custodial account or hand over control of your keys, everything here operates on top of transactions you sign yourself.

Step 1: Get a Flashbots Protect RPC Endpoint

Flashbots Protect is a free RPC endpoint that any Ethereum user can point their wallet or script at. Instead of broadcasting to the public network, it routes your transaction to a private channel of block builders. There’s nothing to install, you just need the URL. The default endpoint is rpc.flashbots.net, and a faster variant that skips some of the privacy delay is available at rpc.flashbots.net/fast.

Confirm the endpoint is live and responding before wiring it into anything:

curl -s -X POST https://rpc.flashbots.net/fast \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_chainId",
    "params": []
  }'

A healthy response looks like this:

{"jsonrpc":"2.0","id":1,"result":"0x1"}

0x1 is Ethereum mainnet’s chain ID in hex. If you get a timeout or connection refused error here, don’t move on to the next step yet, jump ahead to the troubleshooting section below.

Choosing between the default endpoint and the fast variant comes down to a tradeoff between privacy depth and inclusion speed. The default mode holds your transaction in a slightly wider protective window and shares fewer identifying hints with builders, which is the safer default for a large or sensitive trade. The fast endpoint shares a bit more information up front so builders can slot you in sooner, which matters if you’re trading something time-sensitive like a liquidation or a fast-moving arbitrage window. For routine swaps, either works fine, and you can switch between them per-transaction just by changing the URL your provider points at.

Step 2: Connect MetaMask to the Protected RPC

Open MetaMask, click the network dropdown, and choose Add Network manually. Instead of typing the details by hand, you can also trigger the same dialog programmatically from a dApp using wallet_addEthereumChain, which is useful if you’re building a frontend that wants to offer MEV protection as a one-click toggle.

{
  "chainId": "0x1",
  "chainName": "Flashbots Protect (Fast)",
  "rpcUrls": ["https://rpc.flashbots.net/fast"],
  "nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
  "blockExplorerUrls": ["https://etherscan.io"]
}

Once the network is added, switch MetaMask to it before signing any swap you want protected. Everything else about your wallet stays the same, your address, your balances, your approvals. Only the path your signed transaction travels changes.

If you’re using a hardware wallet through MetaMask rather than a hot wallet, the same network switch applies, the signing flow on the device itself doesn’t change at all. The protection lives entirely in how MetaMask forwards the already-signed transaction, not in how it’s signed. That matters because it means pairing a hardware wallet with a protected RPC gives you both key-custody security and MEV protection at the same time, without one interfering with the other.

Step 3: Verify the RPC Is Actually Private

Adding an RPC and trusting that it’s doing its job are two different things. Send a small test transaction, then immediately check a public mempool explorer for its hash. If the transaction never appears in the public mempool and instead shows up directly as mined, the private routing worked. You can also poll the transaction’s status directly through Flashbots’ own API rather than relying on a third-party explorer:

curl -s "https://protect.flashbots.net/v1/transaction/0xYOUR_TX_HASH" \
  -H "Accept: application/json"

A successful response reports the transaction’s inclusion status directly:

{
  "status": "INCLUDED",
  "hash": "0xYOUR_TX_HASH",
  "maxBlockNumber": 23456789,
  "transaction": { "from": "0xabc...", "to": "0xdef...", "gasPrice": "1200000000" }
}

A status of PENDING means it’s still in the private queue waiting for a builder to include it. A status of FAILED means it was simulated and dropped before ever reaching a block, which is actually a feature: Flashbots Protect won’t let a transaction that’s guaranteed to revert cost you gas.

It’s worth running this check a handful of times across different trade sizes before you fully trust the setup. A $50 test swap behaves differently than a $5,000 one in terms of how much a builder prioritizes it, and you want to know your protection holds up at the size you actually trade, not just at toy-transaction scale.

Step 4: Add MEV Protection to a dApp With Ethers.js

If you’re writing a script or a bot rather than clicking through MetaMask, point ethers.js directly at the protected RPC. The hint query parameter controls how much information you share with builders. Sharing more (like the transaction hash and logs) can qualify you for MEV refunds, sharing less maximizes privacy.

import { JsonRpcProvider, Wallet, parseEther } from "ethers";

const protectRpc = "https://rpc.flashbots.net/fast?hint=hash";
const provider = new JsonRpcProvider(protectRpc);
const wallet = new Wallet(process.env.PRIVATE_KEY, provider);

async function sendProtectedSwap(to, data, valueEth) {
  const tx = await wallet.sendTransaction({
    to,
    data,
    value: parseEther(valueEth),
    gasLimit: 300000n
  });
  console.log("Submitted via Flashbots Protect:", tx.hash);
  const receipt = await tx.wait();
  console.log("Confirmed in block:", receipt.blockNumber);
  return receipt;
}

Notice there’s no special “private” method being called here. It’s the same sendTransaction call you’d write for any RPC, the protection comes entirely from which endpoint you point the provider at. That’s deliberate on Flashbots’ part, since it means you don’t have to rewrite existing dApp logic to adopt it.

The refund mechanism deserves a closer look, since it’s one of the more useful details developers miss. When your transaction creates MEV that a builder captures, for example if the trade itself moves a price enough to create an arbitrage opportunity, Flashbots shares a cut of that value back to you rather than letting it disappear entirely into the builder’s margin. The same applies to priority fees on transactions that end up paying more gas than strictly necessary for inclusion. None of this happens automatically if you strip out the hint parameters, since builders need at least some signal about your transaction to calculate what you’re owed. That’s the tradeoff behind the hint=hash and hint=hash,logs parameters in the examples above.

Step 5: Wire MEV-Safe Transactions Into Hardhat

Deployment transactions and admin calls are MEV targets too, especially if a contract does something price-sensitive on deploy. Add a protected network entry to your Hardhat config so any script run with that network flag routes through the private endpoint automatically.

require("@nomicfoundation/hardhat-toolbox");

module.exports = {
  solidity: "0.8.26",
  networks: {
    mainnetProtected: {
      url: "https://rpc.flashbots.net/fast",
      accounts: [process.env.DEPLOYER_KEY]
    }
  }
};

Run your deployment with npx hardhat run scripts/deploy.js --network mainnetProtected and Hardhat handles the rest. If the contract you’re deploying involves financial logic, it’s worth pairing this with a real audit before mainnet launch. We cover that process step by step in our smart contract audit tutorial.

Test the deployment against a local mainnet fork before spending real gas on the protected endpoint. Hardhat’s forking feature lets you simulate the exact deployment sequence against current mainnet state without broadcasting anything, which catches gas estimation issues and constructor errors before they cost you a real transaction fee. Once the fork run looks clean, switch the --network flag to your protected mainnet entry and deploy for real.

Step 6: Enable Polygon’s Private Mempool

Polygon rolled out its own private transaction-submission endpoint, positioning the switch as close to a one-line integration for any dApp already running on the network. The design only touches the write path: transaction submissions go through the private endpoint, while read calls (balances, contract views) can stay on whatever standard RPC provider you already use.

// Reads: any standard Polygon RPC provider works fine
const readProvider = new JsonRpcProvider("https://polygon-rpc.com");

// Writes: swap in your Private Mempool endpoint from the Polygon dashboard
const writeProvider = new JsonRpcProvider(
  process.env.POLYGON_PRIVATE_MEMPOOL_URL
);
const wallet = new Wallet(process.env.PRIVATE_KEY, writeProvider);
// Send transactions through `wallet` as usual; only the submission
// endpoint changed, not your contract calls

Grab your actual Private Mempool URL from the Polygon documentation portal rather than reusing a generic one, since access is tied to your project registration. Polygon frames this as a default security upgrade rather than a niche opt-in, which tells you where the ecosystem is heading: private submission becoming the normal path, not the exception.

What makes this rollout notable is the framing. Polygon isn’t pitching the Private Mempool as an advanced option for sophisticated traders, it’s pitching it as the default way any dApp should submit transactions going forward. For teams already running Polygon infrastructure, that’s a strong signal to treat this migration the same way you’d treat any other routine security patch: schedule it, test it against your existing contract calls, and roll it out rather than leaving it as a someday task.

Step 7: Cover Base, BNB Chain, and Solana With GetBlock

Flashbots Protect and Polygon’s endpoint only help you on Ethereum and Polygon. If your trading also touches Base, BNB Chain, or Solana, node provider GetBlock added MEV-protected RPC endpoints across four networks: Solana, Ethereum, BNB Smart Chain, and Base. Under the hood, GetBlock relays your requests into Merkle’s private mempool and builder infrastructure rather than the public one. The MEV-protected option is available by default to paid shared-node users, free-tier accounts need to upgrade to unlock it, and GetBlock has said a dedicated-node version is coming for higher-volume users.

ToolChains SupportedProtection MethodSetup Effort
Flashbots ProtectEthereum mainnetPrivate RPC to trusted buildersChange RPC URL, no signup needed
Polygon Private MempoolPolygonPrivate transaction-submission endpointRegister project, swap write RPC
GetBlock MEV-protected RPCSolana, Ethereum, BNB Chain, BaseRoutes through Merkle private mempoolPaid tier, change RPC URL
CoW SwapEthereum, Base, Arbitrum, GnosisBatch auctions, intent-based solversTrade through the CoW interface
Jito bundlesSolanaBundled transaction landing via Jito validatorsIntegrate Jito SDK or RPC

Full setup details and current endpoint URLs are in GetBlock’s documentation and Jito’s developer docs if Solana is part of your stack.

Solana’s MEV landscape works differently enough from Ethereum’s that it’s worth calling out separately. Instead of a single dominant private-RPC product, Solana traders route through Jito, which bundles transactions and auctions off the right to land them at the front of a block. A bundle either lands completely or not at all, there’s no partial execution, which removes one entire category of failure mode compared to Ethereum’s private mempools. If your project already touches Solana, integrating Jito’s bundle submission alongside the ethers.js patterns above gives you consistent protection across both ecosystems rather than treating Solana as an afterthought.

Step 8: Layer On Slippage and TWAP Guards

A private RPC stops bots from seeing your transaction, but it doesn’t stop a validator from sandwiching you, and it won’t save you if your own slippage tolerance is set wide enough to eat the loss anyway. Pair the transport-layer protection with an application-layer check that refuses to sign a trade if the quote has drifted too far or the current price looks manipulated relative to its time-weighted average.

function isSlippageSafe(quotedPrice, executionPrice, maxSlippageBps = 50) {
  const diffBps = (Math.abs(quotedPrice - executionPrice) / quotedPrice) * 10000;
  return diffBps <= maxSlippageBps;
}

function isTwapSafe(spotPrice, twapPrice, maxDeviationPct = 2) {
  const deviation = (Math.abs(spotPrice - twapPrice) / twapPrice) * 100;
  return deviation <= maxDeviationPct;
}

50 basis points (0.5%) is a reasonable default for liquid pairs. Tighten it for thin pools, where even a small trade can move price enough to fail a naive check, and loosen it slightly for volatile assets where legitimate price movement between quote and execution is normal.

Run the numbers on a real example. Say a token is quoted at $2.00 with a maximum acceptable slippage of 50 basis points, meaning your floor is $1.99. If the pool's price by the time your transaction would execute has moved to $1.94, the guard function catches a slippage of roughly 300 basis points and throws before you ever sign, saving you from a trade you never actually agreed to. Without that check, a wallet's default 1% or higher slippage tolerance would have let the trade through anyway, which is exactly the gap a sandwich bot is built to exploit even when your RPC is private.

Step 9: Build the Complete MEV-Safe Swap Project

Put the pieces from the last few steps together into one script. This is the version you'd actually run: it routes through a private RPC, refuses trades that fail the slippage guard, and logs whether the transaction landed or reverted without charging gas.

import { JsonRpcProvider, Wallet, parseEther } from "ethers";

const PROTECT_RPC = "https://rpc.flashbots.net/fast?hint=hash,logs";
const provider = new JsonRpcProvider(PROTECT_RPC);
const wallet = new Wallet(process.env.PRIVATE_KEY, provider);

const MAX_SLIPPAGE_BPS = 50; // 0.5%

function isSlippageSafe(quoted, executed, maxBps = MAX_SLIPPAGE_BPS) {
  const diffBps = (Math.abs(quoted - executed) / quoted) * 10000;
  return diffBps <= maxBps;
}

async function mevSafeSwap({ router, calldata, valueEth, quotedOut, minOut }) {
  if (!isSlippageSafe(quotedOut, minOut)) {
    throw new Error("Slippage guard tripped, quote moved too far, aborting");
  }

  const tx = await wallet.sendTransaction({
    to: router,
    data: calldata,
    value: parseEther(valueEth),
    gasLimit: 350000n
  });

  console.log(`Sent privately: ${tx.hash}`);
  const receipt = await tx.wait(1);

  if (receipt.status !== 1) {
    console.warn("Transaction reverted, no gas was charged via Protect RPC");
  } else {
    console.log(`Confirmed block ${receipt.blockNumber}, gas used ${receipt.gasUsed}`);
  }

  return receipt;
}

export { mevSafeSwap };

Call mevSafeSwap with the router address, encoded calldata from your DEX aggregator of choice, and the quote you want to defend. Everything upstream of this function, getting the quote, encoding the calldata, stays exactly the way you'd normally build it with a library like ethers.js or a swap aggregator's SDK.

For a production bot rather than a one-off script, wrap the call site in retry logic that distinguishes between failures worth retrying and failures that mean stop. A slippage guard rejection should never trigger a retry, since resubmitting the same trade into the same bad price is pointless. A network timeout or a 429 from the RPC provider is a different story, that's worth a short backoff and a second attempt. Keeping those two failure classes separate in your error handling avoids the common mistake of a bot that either gives up too easily on transient errors or, worse, keeps hammering a slippage-rejected trade until it eventually clears at a much worse price than intended.

Step 10: Test, Monitor, and Alert on MEV Exposure

Before trusting this in production, run it against a handful of small, real trades and watch what happens. Confirm the transaction hash never surfaces on a public mempool tracker before it's mined. Confirm your fill price matches the quote within your slippage tolerance. Then set up ongoing monitoring, because RPC providers do have outages and silent failures are worse than loud ones.

async function checkProtectStatus(txHash) {
  const res = await fetch(`https://protect.flashbots.net/v1/transaction/${txHash}`);
  const data = await res.json();
  if (data.status === "FAILED") {
    console.error(`ALERT: ${txHash} failed simulation before inclusion`);
  }
  return data.status;
}

Wire that check into whatever alerting you already use, a Slack webhook, a cron job, a simple log file you tail. A trade that silently fails to route privately defeats the entire point of setting this up.

If you're running this at any real volume, keep a simple log of every trade's quoted price versus its execution price over time. A single sandwiched trade might just look like normal market noise, but a pattern of consistently worse-than-expected fills on one specific RPC endpoint is a strong signal that endpoint isn't as private as it claims to be, or that a validator with visibility into your private channel is acting on it. That kind of pattern only shows up if you're tracking execution quality as a metric, not just watching for outright failures.

Putting It Together, and What to Watch For

At this point you have a private RPC wired into a wallet or a script, a slippage guard sitting in front of every trade, and a monitoring check that flags failures before they turn into a pattern of losses. That's the core of a working MEV defense, and it's the same shape whether you're a single trader protecting a personal wallet or a team running an automated strategy at volume. The pieces that follow are about keeping that setup honest over time: the mistakes people make when they first configure it, and the errors you'll actually see in a terminal when something goes wrong.

Common Pitfalls

Relying on a single provider with no fallback. If your one private RPC endpoint has downtime, your transaction submission has nowhere to go. Keep a secondary protected endpoint configured, even if it's a different provider entirely.

Setting slippage too high "to be safe." Wide slippage tolerance is exactly what a sandwich bot needs room to operate in. A private RPC without a tight slippage guard is only half the protection.

Testing only on a testnet. Sandwich bots mostly aren't watching testnet mempools, so a script that looks perfectly protected in testing can still get sandwiched the first time it touches mainnet with real liquidity.

Hardcoding private keys in scripts. Every code sample above reads from process.env for a reason. A key committed to a repo, even a private one, is a much bigger risk than any MEV bot.

Assuming protection transfers automatically across chains. Flashbots Protect only covers Ethereum. Trading on Base or Solana without also configuring GetBlock or Jito leaves those trades fully exposed, even if your Ethereum trades are locked down.

Skipping the verification step in Step 3. It's tempting to add an RPC URL, assume it's working, and move straight to production. Confirming a transaction never surfaced on the public mempool takes two minutes and catches misconfigurations, like a typo in the endpoint URL, before they cost you a sandwiched trade.

Troubleshooting

Most of what goes wrong here falls into a handful of predictable categories: endpoint misconfiguration, gas estimation quirks specific to private RPCs, and rate limits on free tiers. Here's what to check first for each.

  • Transaction stuck pending for over 10 minutes. The default privacy mode has a longer inclusion window. Switch to the /fast endpoint or resubmit with a higher priority fee.
  • wallet_addEthereumChain gets rejected in MetaMask. Usually a chain ID formatting issue. Double check it's hex-encoded (0x1, not 1).
  • No special "private send" method seems to exist. That's expected. Standard eth_sendRawTransaction works fine, the privacy comes from the endpoint, not the method name.
  • "Nonce too low" errors after switching RPC providers mid-session. The old provider's cached nonce is stale. Call getTransactionCount(address, "pending") against the new provider before sending.
  • No MEV refund received on a profitable trade. Refund eligibility depends on the hints you share. Add ?hint=hash,logs to the RPC URL and check the refunds documentation for current terms.
  • Hardhat deployment hangs or fails silently on a protected RPC. Some private endpoints don't expose a pending block for gas estimation. Set an explicit gasLimit instead of relying on auto-estimation.
  • 429 Too Many Requests from a private endpoint. You've hit a rate limit on a free tier. Add retry-with-backoff logic or move to a paid plan for production traffic.
  • Transaction shows confirmed in your script but not yet on a public explorer. Private relays sometimes propagate to third-party explorers a few seconds after inclusion. Check status through the provider's own API first rather than assuming failure.

Advanced Tips

Once the basic setup is working, a few refinements are worth adding for anyone trading meaningful size regularly. Consider splitting a large order into smaller tranches sent minutes apart rather than one block-moving trade, since size itself is a signal even inside a private channel once it lands on-chain. If you're building for multiple chains, keep a small config table mapping each network to its protected endpoint and fail closed (refuse to trade) rather than fail open (fall back to a public RPC) if a protected endpoint is unreachable.

Not every transaction needs this level of protection, and it's worth being honest about when to skip it. A $20 swap on a deep-liquidity pair is rarely worth a sandwich bot's gas cost to attack, so the marginal benefit of routing it privately is small. Where this setup earns its keep is on larger trades, thin-liquidity pairs, and anything programmatic running unattended, exactly the categories where a bot's expected profit clears the cost of attacking you. Scale your effort to your actual exposure rather than wrapping every single transaction in the same machinery.

It's also worth understanding that not every chain carries the same baseline MEV risk, which changes how much this setup actually buys you.

NetworkOrdering MechanismRelative MEV Risk
Ethereum mainnetBuilder auction via MEV-BoostHigh, largest bot population
Arbitrum / OptimismCentralized sequencer, largely first-come-first-servedLower, but not zero
BaseCentralized sequencerModerate, high trading volume attracts bots
PolygonValidator set plus new Private Mempool optionModerate
SolanaLeader-based, Jito bundle marketHigh, active bundle competition

Layer 2 sequencers ordering first-come-first-served reduces one category of risk, but it doesn't eliminate MEV entirely, and a sequencer itself is a form of centralized ordering power worth watching as these networks mature. For anything touching a smart contract you didn't write yourself, pair this transport-level protection with the kind of review process outlined in our smart contract audit guide, and if part of your flow involves moving assets across chains, read through bridging crypto safely before wiring bridge calls into any automated script.

Frequently Asked Questions

What is MEV in crypto?
MEV stands for maximal extractable value, the profit a validator, block builder, or bot can extract by reordering, inserting, or censoring transactions within a block. Sandwich attacks are the version that most affects everyday traders, but the same underlying mechanism also drives front-running of liquidations, arbitrage between DEXs, and NFT mint sniping.

Is Flashbots Protect free to use?
Yes, the standard Flashbots Protect RPC is free for any Ethereum user. You just point your wallet or script at the endpoint, there's no signup or API key required for basic use.

Does MEV protection guarantee I won't be sandwiched?
No. It removes public-mempool bots from the equation, which stops the vast majority of sandwich attempts, but a validator or block builder with visibility into your private transaction could theoretically still act on it. Pairing private routing with a tight slippage guard closes most of the remaining gap.

Do private mempools slow down my transactions?
Sometimes slightly. The default privacy mode on Flashbots Protect can take longer to land than a public transaction because it waits for inclusion within a set block window. The /fast endpoint trades a bit of that privacy delay for quicker inclusion.

Can I use MEV protection on Layer 2 networks?
Yes, but the tooling differs by chain. Polygon has its own Private Mempool endpoint, and GetBlock offers MEV-protected RPCs for Base and BNB Chain. Flashbots Protect itself is Ethereum mainnet only.

Is Flashbots Protect the same thing as Flashbots bundles?
No. Bundles are a tool MEV searchers use to submit atomic groups of transactions to builders. Protect is the consumer-facing product built on top of that same builder infrastructure, aimed at regular users who just want their trade shielded, not at people extracting MEV themselves.

What happens to a failed transaction sent through Protect RPC?
If the transaction would revert, Flashbots Protect simulates it first and drops it before it's ever included in a block. That means you don't pay gas for a transaction that was always going to fail, which is different from how the public mempool behaves.

Do I need to change my smart contract code to get MEV protection?
No. Every method covered in this tutorial works at the transport layer, meaning it changes how a transaction gets from your wallet to the chain, not what the contract itself does. Existing contracts and dApps work without modification.

How much does GetBlock's MEV-protected RPC cost?
It's included by default for paid shared-node subscribers rather than sold as a standalone add-on, while free-tier accounts don't get access to the MEV-protected endpoint. Check GetBlock's current pricing page for exact tier costs, since those change independently of the protection feature itself.

Should small retail traders bother setting this up at all?
For occasional small trades on deep-liquidity pairs, the risk is low enough that it's not always worth the setup time. For anyone trading regularly, running a bot, or moving size on thinner pairs, a private RPC costs nothing on Ethereum and takes a few minutes to configure, which makes it worth doing regardless of trade frequency.