Ethereum: Best Private RPCs for MEV (2026)

Answer first — On Ethereum mainnet in 2026 the phrase "private RPC" actually covers two different jobs that get conflated. Job 1 is user-side MEV protection: a regular wallet user wants their swap routed in a way that can't be sandwich-attacked, and Flashbots Protect or MEV-Blocker is the right tool. Job 2 is searcher-side bundle submission: an MEV operator wants to ship eth_sendBundle to multiple builders simultaneously to maximise inclusion, and the right tool is direct submission to Flashbots, Titan, beaverbuild, rsync-builder and others — usually through an aggregator like MEV-Share or your own multi-builder client. These are different products with different latency characteristics, different risks, and different correct configurations. This guide covers both, and is specifically for Ethereum mainnet — for the multi-chain and self-hosted-RPC discussion see Best RPC nodes for MEV 2026.

Mastery path

• Advanced ETH arbitrage strategies
• Institutional MEV backrunning (2026)
• Flashbots bundles explained
• Private RPC guide (current)
• MEV profitability 2026

Two different "private RPC" jobs

The confusion is so common it's worth being literal:

User-side protection. A regular DEX user submits a swap. If it goes through a public RPC, the swap is visible in the public mempool, where searchers can sandwich it. A "private RPC" for this user is one that doesn't broadcast their pending tx to the public mempool — it forwards it directly to block builders, who include it without leaking the contents to other searchers. The user's job is privacy. Latency is secondary.

Searcher-side submission. A searcher has built a bundle (one or more transactions, including one of theirs and possibly someone else's) and needs it included atomically. A "private RPC" for the searcher is a path that gets the bundle to as many builders as possible, as fast as possible, with the right hint configuration to maximise the chance some builder lands it. Latency is everything.

The same provider often offers both. The endpoints are different. The configuration is different. Mixing them up will burn you.

User-protection RPCs (for wallets, swaps, normal flow)

Practical advice for a normal wallet user: set Flashbots Protect or MEV-Blocker as your wallet's default RPC and forget about it. The latency cost is real (your swap may take an extra block to confirm) but the saved value-extraction far exceeds that cost on any non-trivial trade.

Searcher submission paths

For a searcher submitting a bundle, the modern Ethereum landscape post-merge is multi-builder. No single relay has 100% block share, so you need to fan out:

The 2026 default for serious searchers is to fan-out to at least four builders simultaneously and let the first inclusion win. Single-relay submission is a 30–60% block-share blind spot depending on the day.

What to measure when choosing

Latency to the relay is the headline number, but two other measurements matter as much:

1. p95 inclusion latency, not just p50 RTT. A relay that's fast 50% of the time and stalls the other 50% is worse than a slower-but-consistent one.
2. Builder hint-respect. Do they actually honour your reverting-tx-allowed flag, your minTimestamp, your refund-recipient hints? Some relays silently drop bundles whose hints they don't recognise. Test with a tiny canary on every relay before relying on it.
3. Rate limits and 429 behaviour. Free tiers throttle. During a spike (NFT mint, depeg, liquidations cascade) is exactly when you'll hit the limit. Pay for the tier above the one you think you need.

The WSS latency test and MEV relay status tools benchmark the public faces of these relays from your actual region.

A working searcher configuration in 2026

The configuration below is what most institutional Ethereum-mainnet searchers run in some form:

1. Subscribe to the public mempool through a co-located node (Reth or Geth) plus, optionally, MEV-Share for hint-based flow.
2. For each opportunity, build the bundle including any ordering / refund / hint constraints required by the strategy.
3. Simulate via eth_callBundle at the next-block target. Reject if simulated profit doesn't clear gas + safety margin.
4. Fan out eth_sendBundle to Flashbots + Titan + beaverbuild + rsync-builder simultaneously. Track which relay landed each successful bundle so you can re-weight relays over time.
5. Wait one block. If not included, decide whether to resubmit (path still profitable?) or drop.
6. Log inclusion source per bundle. Over a few thousand bundles a clear picture forms of which relays are working for your strategy and which are dead weight.

The FRB Agent does multi-relay fan-out automatically with builder weights that adjust based on observed inclusion success per route.

Common configuration traps

• Using a user-protection RPC for searcher submission. Flashbots Protect's user endpoint will not accept eth_sendBundle. The right endpoint for bundles is the relay (relay.flashbots.net), not the user RPC.
• Submitting to one relay only. Even Flashbots' block share is well below 100%. Single-relay searchers leave money on the table on every block they could've won through Titan or beaverbuild.
• Forgetting revertingTxHashes. If your bundle includes a tx you expect might revert (e.g. an attempt followed by a fallback), you need to flag it as allowed-to-revert or the relay will reject the entire bundle.
• Ignoring builder hints. Modern relays support hints for refundRecipient, minBaseFee, maxBaseFee, target slot, target block. Defaulting these wastes inclusion probability.
• Shipping the same bundle to MEV-Share that you ship to Flashbots Relay. They have different schemas. MEV-Share is a hint protocol; the Flashbots Relay is a bundle endpoint. Mixing them up looks fine in dev and silently fails in production.

Reality check on latency

For Ethereum mainnet, sub-150 ms RTT to your bundle relay is enough. Block times are 12 seconds. The marginal value of going from 80 ms to 30 ms is much smaller than the marginal value of getting your fan-out right or your simulation right. Operators chasing single-digit-millisecond latency to a relay are usually optimising the wrong thing — the bottleneck is almost always somewhere else (mempool ingestion, simulation cost, builder hint-handling, or just bad strategy).

The exception is searchers operating on the same block alongside MEV-Boost auction dynamics — there, every millisecond before the auction's deadline can swing inclusion. Most searchers are not in that regime.

References

• Flashbots Protect documentation
• MEV-Blocker (CoW DAO)
• Flashbots Relay & eth_sendBundle reference
• MEV-Share spec