Which MEV protection RPC is the most consistent?
Data as of , refreshed continuously.
Wallet teams picking a default MEV protection RPC usually compare medians, because medians are what marketing pages publish. But a wallet calls its RPC constantly: every open screen triggers balance refreshes, gas estimates and eth_call simulations. At that call volume the user experiences the p99, not the p50. A gateway that answers in 33 ms most of the time but stalls to 400 ms on one call in a hundred produces a wallet that feels randomly broken several times per session. This page reads the live OpenChainBench mev-protect-rpc benchmark through the consistency lens: which of the public keyless gateways (Flashbots Protect, MEV Blocker, Blink, bloXroute Protect, BlockSec, 48 Club, PancakeSwap MEV Guard) keeps its tail closest to its median.
Live leaderboard, top 5

bloXroute Protect
#1 · Wallet call latency
9msp99 13 ms
48 Club Privacy RPC
#2 · Wallet call latency
22msp99 24 ms
PancakeSwap MEV Guard
#3 · Wallet call latency
26msp99 29 msMEV Blocker
#4 · Wallet call latency
33msp99 262 msBlink
#5 · Wallet call latency
97msp99 103 ms
Full live data: /benchmarks/mev-protect-rpc, refreshed every minute.
Methodology and data sources
Same data as the parent benchmark. Every 60 seconds, from us-east, eu-west and Singapore, the harness sends the 7-method wallet set (chainId, blockNumber, gasPrice, getBalance, call, estimateGas, feeHistory) to each public MEV protection gateway, keyless, one request per 1.5 seconds. The per-tick median across served methods feeds a Prometheus gauge; p50, p90 and p99 are quantile_over_time over 24 hours, averaged across regions. Consistency is read as the ratio between the p99 and p50 columns of the same provider. No transactions are sent; this is the read path a wallet exercises all day.
What this number does not tell you
- ·Consistency of the read gateway says nothing about inclusion rates or refund economics, which are write-path properties requiring funded transactions to measure. OpenChainBench does not extrapolate them.
- ·A flat tail with a moderate median can coexist with a fast median and a heavy tail. Which profile is better depends on the product: trading bots care about the median, consumer wallets about the tail.
- ·Success rate must be read next to both numbers. A gateway can post flat latency while throttling a share of calls; throttled calls do not enter the latency distribution.
Frequently asked questions
- Which MEV protection RPC has the flattest latency tail?
- Blink (formerly Merkle) currently posts the flattest p99 to p50 ratio of the measured cohort on Ethereum, with a tail within roughly 10 percent of its median. The live columns on the benchmark page update every minute and the ranking can move; the ratio between the p99 and p50 columns is the number to read.
- Why does consistency matter more than median latency for a wallet?
- Because a wallet fires dozens of RPC calls per session. At 50 calls per session, a 1-in-100 stall hits most sessions at least once. The user does not experience the median; they experience the worst call on the screen they are currently looking at.
- Is the fastest median MEV protect RPC also the most consistent?
- Not currently. The gateway with the best p50 on Ethereum shows a p99 an order of magnitude above its own median, while the most consistent gateway trades a slower median for a nearly flat tail. The benchmark page shows both columns side by side so the trade-off is explicit.
- Does this ranking cover Base and BSC too?
- The parent benchmark measures Ethereum, Base and BSC as separate chain tabs. On Base only one MEV protection gateway is measurable keyless today (Blink); on BSC the cohort includes Blink, bloXroute Protect, 48 Club, PancakeSwap MEV Guard and BlockSec, so the consistency comparison is meaningful there as well.
Related questions
Same data as /benchmarks/mev-protect-rpc, refreshed every minute. Open methodology, open source.