One Flag, No Sandwich: MEV-Protected Transactions Are Live

By John Sullivan · August 26, 2026 · 3 min read · #mev #ethereum #announcement #protect

Every transaction you broadcast to Ethereum's public mempool is visible to thousands of bots before it mines. If it's a swap with slippage tolerance, some of them will sandwich it — buy before you, sell after you, and pocket the difference out of your execution price. This isn't rare or exotic: it's an industrialized pipeline, and the public mempool is its feedstock.

As of today, avoiding it on SwiftNodes takes one query parameter:

https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY&protect=1

With protect=1, any eth_sendRawTransaction on that connection is routed to a private transaction relay — currently MEV Blocker — instead of the public mempool. Sandwich and front-running bots never see your transaction, because there's nothing to see: it goes from us to the relay to block builders, privately.

What changes, and what doesn't

Only sends are affected. Every read — eth_call, eth_getLogs, subscriptions, all of it — routes through the normal load-balanced pool exactly as before. You don't need a second endpoint for reads and writes; the same URL does both, with sends taking the private path. Point your existing signer at the flagged URL and you're done:

import { createWalletClient, http } from "viem";
import { mainnet } from "viem/chains";

const client = createWalletClient({
  chain: mainnet,
  transport: http("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY&protect=1"),
});
// sendTransaction / sendRawTransaction now skip the public mempool

You may get paid for your own backruns. We picked MEV Blocker as the relay deliberately: when searchers capture value by backrunning your transaction (the benign kind of MEV — arbitrage after your trade moves a price), MEV Blocker auctions that right and rebates most of the proceeds to you, the transaction origin. The predatory MEV is blocked; the extractable-anyway part partially comes back to your address.

Nothing to sign up for, nothing extra to pay. The flag works on every plan — including the free tier. We pass your transaction to a public-good relay; there's no markup and no metering (there's never metering here).

The semantics that matter

We built the routing with the care a transaction path demands:

  • Exactly one submission. Protected sends are relayed once, with no retry and no failover — a send must never risk being double-submitted. If the relay errors, you get its error verbatim and can decide what to do.
  • Honest scope. This is Ethereum mainnet only for now — that's where mature private relays live. Using protect=1 on any other chain returns a clear 400: MEV-protected sends are not available for this chain, never a silent fallback to the public mempool. (BSC is the likely second chain; its relay ecosystem is on our list to evaluate.)
  • Batches are rejected with protect=1 — send transactions individually so each one's relay semantics stay unambiguous.
  • Inclusion timing: private transactions can take marginally longer to land than a public broadcast, and MEV Blocker falls back to public broadcast if a transaction isn't included within its window — your transaction won't get stranded. Poll eth_getTransactionReceipt exactly as you always would.

Who should turn this on

  • Anything that trades: bots, keepers, rebalancers, treasury operations — any eth_sendRawTransaction whose contents move a price is sandwich bait in the public mempool.
  • Liquidations and time-sensitive calls that competitors would love to observe and front-run.
  • Deployments and admin operations where you'd simply rather not telegraph your next move to every mempool watcher.

Who shouldn't bother: pure-read workloads (nothing to protect), and transactions with no extractable value (a plain ETH transfer between your own wallets can't be sandwiched — though routing it privately costs nothing either).

Why this was the missing column

If you've read our normalized pricing comparison, you know we think about provider features honestly — including the ones we lacked. MEV protection was a column where Infura and dRPC had a check mark and we had a dash. As of today it's a check mark, implemented the way we prefer: no separate product, no add-on pricing, one flag on the endpoint you already use, documented in the API reference.

Try it with a key from the free tier — and if you want the full background on how sandwiches, builders, and private relays actually work, start with What is MEV? A developer's plain explainer.

J
John Sullivan
Infrastructure Writer, SwiftNodes

John Sullivan covers RPC infrastructure, node operations, and multi-chain development at SwiftNodes — what it actually takes to keep endpoints fast, fresh, and reliable across EVM and non-EVM networks.

Related posts

  • What Is MEV? A Developer's Plain Explainer

    MEV — maximal extractable value — is why your swap sometimes executes at a worse price than you saw, and why validators reorder transactions for profit. A plain-English tour of front-running, sandwiches, and back-running, how the public mempool enables it, and what you can actually do about it.

  • Best Ethereum RPC Providers (2026): Pricing, Free Tiers and Limits Compared

    Seven Ethereum RPC providers compared on current pricing, free tiers and measured limits, with what 30M and 100M requests a month cost on each. Pricing checked October 3, 2026.

  • Ethereum RPC: The Complete Developer Reference

    Everything you need to connect to Ethereum via RPC — the methods you'll actually use, how to set up viem and ethers, WebSocket vs HTTP, archive access, and how to pick an endpoint that won't fall over under load.

Try SwiftNodes free — multi-chain RPC across 83 networks, flat-rate pricing, pay by card or crypto, no KYC. Get an API key in 30 seconds →