How MEV Watch measuresEthereum censorship.
MEV Watch tracks the share of Ethereum block flow that passes through OFAC-censoring relays in the MEV-boost ecosystem. This page explains what that means, where the data comes from, how the metric is calculated, and where the approach falls short.
One number, one question.
MEV Watch answers one question: what fraction of Ethereum MEV-boost block flow is currently delivered through relays that apply OFAC sanctions filtering?
When that number is high, the majority of validators are building on blocks curated by censoring infrastructure — meaning OFAC-sanctioned transactions (such as interactions with Tornado Cash contracts) are systematically excluded from a large proportion of Ethereum blocks. When it is low, most block flow passes through relays that include all valid transactions regardless of origin.
The metric is a daily snapshot derived from relay-level payload delivery counts. It does not measure on-chain transaction inclusion directly, but relay market share is a reliable leading indicator of censorship pressure on Ethereum's block production pipeline.
How block flow works.
MEV-Boost is an out-of-protocol sidecar run by most Ethereum validators. Instead of building blocks locally, a validator running MEV-Boost outsources block construction to a competitive market of block builders who submit their best blocks to relays — trusted intermediaries that validate and auction those blocks to validators.
Each relay operates its own inclusion policy. Some relays (classified here as censoring) instruct their builders to exclude transactions involving OFAC-sanctioned addresses before submitting a bid. Other relays (classified as neutral) apply no such filter and include all valid transactions.
Because most validators connect to multiple relays simultaneously and accept whichever relay offers the highest-value block for each slot, the aggregate share of payload deliveries across censoring relays is a proxy for how often censoring infrastructure wins the block auction.
Where the numbers come from.
All relay market-share data is sourced from relayscan.io, a Flashbots-maintained relay analytics service. MEV Watch consumes its public JSON API at the endpoint:
GET /stats/day/{date}/jsonA scheduled Vercel Cron job runs shortly after each UTC day rolls over, fetching the previous day's stats and writing them into a SQLite artifact stored in Vercel Blob. Normal page loads read only that artifact — they do not query relayscan.io.
Each API response includes a per-relay count of payload deliveries: the number of times each relay successfully returned a signed execution payload to a requesting validator. This is the raw figure used to compute the censorship metric.
The censorship percentage.
The daily censorship percentage is defined as:
Censorship % = deliveries via censoring relays / total deliveries across all relays
Both the numerator and denominator count payload deliveries, not unique blocks. This is intentional. When a validator connects to multiple relays, more than one relay may deliver a payload for the same slot — relayscan counts each delivery separately, meaning a single block can contribute more than once to the total. Using a ratio (share) rather than a raw block count is the honest approach: the multi-relay double-counting cancels between numerator and denominator, so the ratio accurately reflects the relative weight of censoring relay flow.
Concretely: if censoring relays collectively deliver 40 out of 100 total payloads on a given day, the censorship percentage is 40%, regardless of whether some of those payloads corresponded to the same underlying block. The ratio is consistent because any double-counting affects both sides equally.
Posture by relay.
Whether a relay applies OFAC sanctions filtering is an editorial judgement — it cannot be inferred from on-chain data alone. MEV Watch maintains this classification by hand in src/data/relays.json. Posture assignments are sourced from the ethstaker MEV relay list and public statements by relay operators. The list is reviewed whenever relays are added or change their policy.
Relays with an unknown posture are treated as non-censoring in the metric until their policy can be confirmed. Unconfigured relays that appear in relayscan data but are not in this list are also treated as unknown and excluded from the censoring total.
Where the metric falls short.
MEV Watch is a useful first-order signal, but it is not a complete picture of Ethereum censorship. The following limitations apply:
- 01
Relay-level posture, not per-block measurement
The censorship classification is applied at the relay level, not verified per block. A relay labelled censoring may occasionally include sanctioned transactions if its upstream builders do, and vice versa. MEV Watch does not inspect individual block contents.
- 02
Locally-built blocks are not counted
Validators that build blocks locally (without MEV-Boost) are not part of the MEV-Boost flow and therefore not counted in either the numerator or the denominator. The non-boost composition band on the dashboard shows their share of the overall chain separately. Because local blocks tend to be censorship-neutral, the censorship percentage may overstate the true proportion of all Ethereum blocks that are censored.
- 03
Editorial classification can lag policy changes
Relay operators sometimes change their filtering policy without public announcement. The
relays.jsonclassification is updated manually when changes are detected. There may be a lag between a real-world posture change and the update reflected here. - 04
Headline is daily; the live ledger is a separate view
The headline censorship percentage is a daily snapshot. Intra-day changes in relay composition do not move it until the next UTC day's snapshot refresh (now persisted as a SQLite artifact in Vercel Blob). The epoch ledger on the dashboard polls the relays' own data APIs and displays per-slot outcomes on a much shorter refresh window, but is scoped to the last ~1024 slots and is not used to compute the headline percentage.