One Flag, No Sandwich: MEV-Protected Transactions Are Live
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=1on any other chain returns a clear400: 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_getTransactionReceiptexactly as you always would.
Who should turn this on
- Anything that trades: bots, keepers, rebalancers, treasury operations — any
eth_sendRawTransactionwhose 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.