​

⏱️ MEV Timing Games

MEV timing games are a deliberate strategy where Ethereum validators delay their block proposals to capture higher rewards from the relay market. beaconcha.in tracks this behaviour per-block and per-validator so you can see exactly where on the spectrum each proposal falls. This page covers:

1. What MEV Timing Games Are
2. Can You Play Them by Accident?
3. The Timing Spectrum
4. Understanding the Bids
5. The Timing Histogram
6. Risk vs. Reward
7. Network Effects
8. Exploring MEV Data on beaconcha.in
9. What’s Coming: Glamsterdam

---

​

What Are MEV Timing Games?

​

The Ethereum slot clock

Every Ethereum slot is exactly 12 seconds long. When a validator is scheduled to propose a block, the sequence looks like this: The t = 4 s attestation deadline is the critical boundary. Attesters vote for whichever block they have seen at that moment. A block that arrives after 4 s risks being ignored by a large fraction of the committee, increasing the chance it is orphaned from the canonical chain entirely.

​

Where MEV fits in

Most validators don’t build their own blocks. Instead they use MEV-boost, which queries multiple relays (trusted intermediaries between block builders and validators). Each relay returns the highest-value sealed block it has received from competing builders. At t = 0, the validator’s consensus client calls get_header. MEV-boost queries all connected relays simultaneously, selects the highest bid, and must return a signed header back to the validator within roughly 1 second (the default MEV-boost timeout is 950 ms, leaving a small buffer before the hard protocol limit).

​

What a timing game is

A timing game is the deliberate decision to delay calling get_header — or to wait for a higher bid to arrive before committing — beyond the time that would be needed for a timely proposal. The reasoning: builders need time to collect and order transactions. Waiting an extra second or two gives builders more profitable transactions to include, which lifts their bids. The tradeoff is that the later the block arrives at the network, the fewer attesters will have seen it by t = 4 s.

---

​

Can You Play Them by Accident?

Yes — and it is more common than most validators realise. A block arriving at 1.3 s registers as “Timing Games” in our classification, even if the operator had no intention of delaying. Real-world sources of accidental delay include:

• Relay response latency — a relay being slow to respond can push the get_header call past the 950 ms window, causing the next available slot to be chosen later than intended.
• Network propagation — a block signed at 1.0 s still needs time to propagate; by the time it is seen by remote nodes, the clock has moved forward.
• Validator client processing — signing and broadcasting adds a few hundred milliseconds on modest hardware.
• Geographic distance to relays — validators far from relay infrastructure experience higher round-trip latency on every get_header call.

The classification thresholds (1.2 s / 2.6 s) are therefore not a binary “cheating” indicator. Low timing values are often noise. Only consistent patterns towards the aggressive end of the scale are a reliable signal of intentional behaviour.

---

​

The Timing Spectrum

beaconcha.in measures slot_t_ms — the number of milliseconds from the start of the slot to the moment the winning relay bid was committed to (as reported by relay data archives). Each proposal is assigned one of four categories: The colour is not a step function — it is a continuous gradient interpolated across six anchor points (0 ms → deep green, 1,100 ms → healthy green, 1,200 ms → yellow, 2,400 ms → orange, 2,600 ms → bright red, 3,500 ms → deep red). Values above 3,500 ms are clamped to the deepest red.

​

On-Time MEV

The block was proposed promptly. The relay bid arrived and was signed within the ~1 s window that MEV-boost is designed for. No deliberate delay is evident. MEV extraction is happening, but transparently and without network cost.

​

Timing Games

The block was proposed more than 1.2 s into the slot. This covers a wide range: modest delays (1.2–2 s) that may be partially accidental, through to clearly intentional delays approaching 2.6 s. Higher values within this band increase the fraction of attesters that will not have seen the block by t = 4 s.

​

Aggressive Timing Games

The block was proposed more than 2.6 s into the slot. At this point the validator is taking a significant risk of missing attestations. Empirically, blocks arriving near 3.5 s or later have almost no network-propagation buffer before the attestation deadline, and operators proposing consistently in this range are sacrificing network health for marginal extra MEV.

---

​

Understanding the Bids

The slot page shows up to three bid markers on a timing timeline for each MEV block:

​

Winning Bid

Green circle — the relay bid the validator actually selected and signed. This determines both the ETH reward and the slot_t_ms timing used for classification.

​

First Better Bid

Blue square — the earliest bid that arrived after the winning bid and offered a higher value. Because the horizontal axis is time, not reward, this marker shows how much longer the proposer would have had to wait to capture a better bid. If it sits close to the winning bid, only a small timing-game delay — with little added orphan risk — would have captured that extra value. The further to the right it sits, the more aggressive the timing game required, and the more orphan risk the proposer would have taken on to reach it. The First Better Bid is only shown when it differs from the Best Possible Bid.

​

Best Possible Bid

Purple diamond — the highest value bid that arrived after the winning bid. This is the theoretical maximum: what the validator could have earned had they waited until that exact moment and then committed. The difference between the Winning Bid and the Best Possible Bid represents the maximum amount left uncaptured.

---

​

The Timing Histogram

The validator dashboard MEV tab shows a histogram of slot_t_ms values across all MEV blocks proposed by the validators in your dashboard.

• The chart spans from < 0 ms (bids committed before the slot officially started) to ≥ 4,000 ms, split into 22 buckets of 200 ms each.
• Each bar is coloured using the same continuous gradient as the individual block badges — green on the left, red on the right.
• The overall timing label shown above the histogram is determined by the median slot_t_ms across all relay-winner proposals, giving a representative single number for the validator set.
• Blocks with no relay participation (No MEV) and blocks where the relay reported no winner are excluded from the histogram and timing label — they are accounted for separately.

Reading the histogram:

• A distribution concentrated in the 0–1,200 ms range indicates prompt, on-time proposals.
• A distribution spread across 1,201–2,600 ms suggests mild to moderate timing games, possibly a mix of intentional and accidental delay.
• Any significant bar at or beyond 2,600 ms — especially towards 3,500 ms — is a strong signal of intentional aggressive timing game behaviour.

---

​

Risk vs. Reward

The economic logic of timing games is straightforward: the longer builders have to observe pending transactions, the more profitable blocks they can construct. Research has estimated that optimal timing can improve overall validator APR by roughly 1–2% for sophisticated operators. The risk is also straightforward: the later a block arrives at the network, the fewer attesters will have seen it by the t = 4 s deadline. Empirical data from testnet observations shows that blocks arriving near 3–3.5 s can lose ~10% of attestations to wrong-head votes, directly reducing the CL reward. In extreme cases, a block arriving after 4 s may be entirely skipped by attesters, resulting in the slot being treated as missed — losing the entire block reward. The risk is therefore asymmetric and non-linear: modest timing (1.2–1.8 s) carries limited risk, but delays approaching 3.5 s carry a substantially higher chance of orphaning the block and turning a reward into a missed slot.

---

​

Network Effects

Timing games are not purely a private risk — they have externalities that fall on other validators. A direct financial cost to innocent attesters: This is the most concrete harm. Consider a simple example: you propose a late block at t = 2.5 s. Alice is randomly assigned to attest in your slot. She polls the network at t = 4 s and has not yet seen your block, so she votes for the previous block — a wrong-head vote. Meanwhile, the majority of attesters did receive your block in time and vote correctly. The network accepts your block as canonical. The result: Alice loses the head vote component of her attestation reward for that slot, through no fault of her own. She voted correctly for what she could observe. The cost of your timing game was partly shifted onto her. This is a negative externality in the economic sense: you capture extra MEV, but a portion of the cost is borne by validators who had no part in the decision. Attestation quality and fork-choice stability: Beyond the per-validator penalty, a high rate of wrong-head votes degrades the overall quality of consensus information. Fork-choice becomes noisier, and in edge cases the split can be exploited to mount certain fork-choice attacks. A network where many proposers consistently play aggressive timing games is structurally weaker than one where blocks arrive promptly. Orphan propagation: A block that is not seen by enough attesters in time may trigger a re-org, forcing the next proposer to build on a different parent. This disrupts any validators who built on the orphaned tip, potentially invalidating their attestations as well. Centralisation pressure: Effective timing games require fast, low-latency connections to multiple relay endpoints. Large staking pools with dedicated relay infrastructure and co-located validators can execute timing games more safely than solo stakers on commodity hardware at home. This creates an unequal playing field — operators with better infrastructure can capture more MEV at lower orphan risk. The academic literature frames timing games as “honest-but-rational” behaviour: validators are acting within the rules of the protocol while extracting value that could otherwise belong to the network as a whole. There is no community consensus on whether they are unethical, but they are widely viewed as a network health concern, particularly at the aggressive end of the scale.

---

​

Exploring MEV Data on beaconcha.in

The same underlying timing data is surfaced at six levels of granularity, from a single block all the way to a network-wide 30-day view. Each answers a different question.

​

Individual block — Slot page

beaconcha.in/slot/{slot} The most granular view. For every MEV block it shows:

• A timing badge on the Proposer Reward line, colour-coded by slot_t_ms and labelled with the timing category. Hover the badge for the exact millisecond value and a link to the timing spectrum explainer.
• A MEV Bid Analysis section plotting all three bid markers — Winning Bid, First Better Bid, and Best Possible Bid — on a timeline against the slot clock. This lets you see exactly how much value the proposer captured, what was left on the table, and how close to the attestation deadline the block arrived.

Use this when you want to understand a specific proposal in full detail.

​

Individual validator — Validator page

beaconcha.in/validator/{index} The validator detail page adds a MEV tab showing:

• A timing label summarising the validator’s overall timing posture.
• A 180-day MEV distribution chart — a histogram of slot_t_ms values across all proposals in the past 180 days, coloured with the same gradient as the timing badges. This reveals whether timing patterns are consistent or episodic, and whether they are drifting over time.

Use this when you want to profile a single validator’s timing behaviour over a longer window.

​

Your validator set — Dashboard

beaconcha.in/monitoring/dashboard The validator dashboard surfaces MEV data in two places: Blocks table — every proposed block row includes a MEV status badge and bid insight details: the winning bid value, timing, relay and bid counts, and the best alternative bid that was available. This gives you a running log of MEV outcomes across your entire set without needing to visit each slot individually. MEV tab — an aggregated view across all validators in the dashboard showing:

• An overall timing label (based on the median slot_t_ms across all relay-winner proposals), with a link to the timing spectrum explainer.
• A bid timing histogram across all 22 buckets. See the histogram section for how to read it.

Use this when you want to answer “how are my validators performing on timing, in aggregate?”

​

Staking operator — Entity detail page

beaconcha.in/entities → click any entity → beaconcha.in/entity/{name} The entity detail page aggregates MEV data across every validator operated by a staking entity (e.g. Lido, Coinbase, solo stakers). It shows:

• A 180-day MEV distribution chart — the same histogram format as the individual validator page, but representing thousands of proposals aggregated by operator. Overlaid on the chart is the max bid value in ETH, showing whether higher-timing proposals actually capture higher rewards.
• A MEV trend chart — a time-series of the entity’s median slot_t_ms over the past 180 days, with reference lines at 1,200 ms and 2,600 ms marking the spectrum thresholds. This makes sustained timing game behaviour or gradual drift clearly visible.
• Sub-entity timing labels in the sub-entities table, showing the MEV posture for each sub-entity (e.g. individual node operators within a liquid staking protocol).

Use this when you want to assess whether a large staking operator is systematically playing timing games, and how the behaviour compares across their sub-entities.

​

All operators at a glance — Entities overview

beaconcha.in/entities The entities overview page lets you compare all major staking operators side-by-side. Two MEV features are available:

• MEV timing column in the entities table — a timing label badge per operator showing their overall MEV posture at a glance.
• MEV heatmap treemap — toggle the treemap from Performance mode to MEV Timing mode to see the entire staking landscape coloured by timing behaviour. Larger squares represent more stake; deeper red indicates more aggressive timing games.

Use this when you want to identify which large operators are the most active timing game players across the network.

​

Network-wide trends — MEV Analysis

beaconcha.in/mev The broadest view. A 30-day stacked bar chart of daily slot counts broken down by all five timing categories: No MEV, Unknown Timings, On-Time MEV, Timing Games, and Aggressive Timing Games. The 7-day summary cards at the top give an at-a-glance percentage for each category. Use this to track whether timing game behaviour is growing or shrinking across Ethereum as a whole — useful context for interpreting what you see at any of the more granular views above.

---

​

What’s Coming: Glamsterdam

The current timing game dynamic is a consequence of the relay architecture: relays sit outside the protocol, creating the gap between the 1 s MEV-boost deadline and the 4 s attestation deadline that validators can exploit. Glamsterdam, the next Ethereum protocol upgrade, will introduce enshrined Proposer-Builder Separation (ePBS) — moving the builder auction mechanism directly into the consensus layer. Relays as they exist today will be replaced by a protocol-native mechanism, and the timing game landscape will change significantly as a result. We will share a detailed breakdown of what ePBS means for timing game metrics on beaconcha.in as the hardfork approaches.

---