DEV Community

SwiftNodes
SwiftNodes

Posted on Originally published at swiftnodes.io

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.


Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Top comments (0)