I was investigating head vote accuracy patterns in Ethereum mainnet and stumbled onto something striking: there's a cliff.
Blocks that arrive within the first 3 seconds of a slot have ~99% head accuracy. Blocks that arrive in the 3-4 second window drop to 89%. But blocks that arrive after 4 seconds? They plummet to near-zero.
The attestation deadline creates a cliff. Blocks arriving after 4 seconds have essentially no head votes.
The answer is in the consensus spec. Validators are supposed to attest 4 seconds into each 12-second slot. That's one-third of the slot, giving the proposer time to build and broadcast a block, while leaving time for attestations to propagate.
If the block hasn't arrived by attestation time, validators must attest to what they know: the previous head. So when a block finally shows up late, every validator who already attested is now "wrong" in the sense that their head vote doesn't match what became the canonical head.
| Block Arrival | Slots (7 days) | Avg Head Accuracy | Zero-Accuracy Slots |
|---|---|---|---|
| <1 second | 779 | 99.4% | 0 |
| 1-2 seconds | 12,653 | 99.7% | 1 |
| 2-3 seconds | 6,769 | 99.3% | 0 |
| 3-4 seconds | 1,298 | 88.8% | 1 |
| 4-5 seconds | 18 | 2.1% | 1 |
| 5-8 seconds | 20 | 0.02% | 1 |
| >8 seconds | 1 | 0.02% | 0 |
The 3-4 second "danger zone" affects about 6% of blocks daily. These blocks cause most of the head accuracy degradation we see on the network.
Head accuracy issues peak between 4-7 AM UTC. During this window, about 5% of slots have degraded head accuracy (<95%), compared to ~2.5% during peak hours (9 PM UTC).
5-6 AM UTC is the worst window, with 2.5% of slots showing extreme head accuracy drops (<80%).
Interestingly, this doesn't perfectly correlate with late block arrivals. The 5 AM UTC spike suggests network propagation issues—validators receiving blocks slower—rather than proposers being late.
Your head vote accuracy matters for rewards. If you're consistently receiving blocks late due to network position or slow peers, you'll have lower accuracy even when doing everything right.
Pushing block delivery to the last millisecond before the 4-second deadline is a risky game. Any propagation delay tips you over the cliff.
The 4-second deadline creates a sharp discontinuity in network behavior. About 6% of blocks arrive in the danger zone (3-4s), and any of these can trigger cascading accuracy drops if propagation is slow.
Source: mainnet.fct_attestation_correctness_by_validator_head and mainnet.fct_block_first_seen_by_node (xatu-cbt cluster)
Date range: 2026-01-26 to 2026-02-02 (7 days)
Slots analyzed: ~50,000
SELECT
slot,
countIf(slot_distance = 0) * 100.0 / COUNT() AS head_accuracy_pct
FROM mainnet.fct_attestation_correctness_by_validator_head FINAL
WHERE slot_start_date_time >= now() - INTERVAL 7 DAY
GROUP BY slotWITH head_accuracy AS (...),
block_arrival AS (
SELECT slot, MIN(seen_slot_start_diff) AS first_block_ms
FROM mainnet.fct_block_first_seen_by_node FINAL
...
)
SELECT arrival_bucket, AVG(head_accuracy_pct) ...The attestation deadline at 4 seconds creates a hard boundary in network behavior. This is by design—it ensures validators can't wait indefinitely for blocks—but it means any block arriving after the deadline gets punished with near-zero head votes.
The 5-6 AM UTC pattern suggests there's room for network optimization during low-traffic hours, when propagation seems slower despite similar block production timing.