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

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.

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.

  • Ethereum Light Clients: Verified Data Without Running a Node

    A light client verifies Ethereum's headers against the validator set on your laptop — turning any untrusted RPC endpoint into a verified one. How sync committees work, what Helios-style clients actually do, and their honest limits.

  • eth_getProof: Verify Blockchain State Without Trusting Your RPC Node

    Every eth_call answer is just something a server told you. eth_getProof returns state with a Merkle proof you can check yourself — the primitive behind bridges, light clients, and trust-minimized reads.

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