Composite score
78.5
Rank 7 of 12
38,894 samples
Providers
MEV BlockerGood
Public Ethereum RPC with MEV protection for transaction submission. Read methods are unrestricted.
public · rank 7 of 12
Website (opens in a new tab)Documentation (opens in a new tab)
Measured performance
24h window · 24 hours observed · 1 chain
Availability
99.87%
Rate limits and unsupported methods excluded
Latency p95
128.2ms
p50 44.1 · p99 206.4
Correctness
99.99%
38,846 responses judged
12 providers scored against each other.
Score breakdown
| Component | Weight | Measured | Score |
|---|---|---|---|
| Availability | 40% | 99.87 % | 99.9 |
| Latency | 30% | 128.15 ms | 30.4 |
| Correctness | 20% | 99.99 % | 100.0 |
| Head freshness | 10% | 0.42 blocks behind | 94.9 |
Outcome breakdown
Failures are classified rather than collapsed into one count. Our own failures are shown for transparency but are never counted against the provider.
| Outcome | Count | Share |
|---|---|---|
| Successful | 38,842 | 99.87% |
| Provider failure | 4 | 0.01% |
| Network failure | 48 | 0.12% |
| Rate limited | 0 | 0.00% |
| Unsupported method | 0 | 0.00% |
| Agent error | 0 | 0.00% |
| Measurement error | 0 | 0.00% |
What it says it permits
The only figures on this site that are not measurements. A limit is a claim the operator makes, so it is quoted with the page it came from and the day it was read — never inferred from a refused request, which would put a number against a company that never stated it.
MEV Blocker does not publish a numeric limit that could be found in its own documentation. Several public endpoints state only that a request may be refused — which is worth knowing before depending on one, and is why this says so rather than showing nothing.
What it promises about staying up
The status page judges every provider against an objective this site publishes. That is not an SLA, and a provider that misses it has not broken a promise — so what it actually promised, where it promised anything, belongs here in its own words. The objective
MEV Blocker does not publish an availability commitment that could be found in its own documentation. That is the common case for a public endpoint and is worth knowing before depending on one: the availability figures on this site are measurements against a bar this platform set, not against anything MEV Blocker agreed to.
Reliability record
An availability percentage has no shape. This is the shape: what departed from this provider’s own normal behaviour, and what its normal behaviour already is. How an incident is decided
Departures from normal · last 30 days
None. Across the last 30 days, MEV Blocker did not depart from its own usual behaviour on any measured call for long enough to count as an incident.
Persistent conditions
None. Every call measured on MEV Blocker succeeded often enough, often enough of the time, not to qualify.
From each region
The same measurements, grouped by the vantage point they were taken from. Latency is a property of a network path, so a provider fast from one region is not necessarily fast from another — and the composite score above is an average across whichever regions are reporting.
Frankfurt
Amsterdam
Coventry
VirginiaPercentiles are over successful responses only. A request that timed out is not a latency sample; it is counted against availability instead.
Endpoints under measurement
EthereumEmbed this
A live badge for MEV Blocker on Ethereum, free to use. It renders from the current measurement each time it loads, so it cannot be frozen at a good day — which is what makes it worth putting in a README. Every badge and parameter
scoreThe composite score, coloured by band.
Markdown
[](https://rpcnode.io/providers/mevblocker)HTML
<a href="https://rpcnode.io/providers/mevblocker"><img src="https://rpcnode.io/badge/provider/mevblocker.svg?chain=ethereum" alt="MEV Blocker on RPCNode.IO"></a>