Over a 3-hour window, Prysm nodes recorded 845 observations where blocks arrived more than 30 seconds after the slot start. Of these, 521 took over 5 minutes, and the worst case hit 776 seconds (nearly 13 minutes).
This isn't a few stragglers. With 41,956 total observations from Prysm nodes, approximately 2% of all block arrivals experienced extreme delays. The average arrival time for Prysm was 9.76 seconds compared to 2.1-2.2 seconds for well-performing clients like Teku, Nimbus, and Lighthouse.
Lodestar posted the most extreme single observation: a block arriving 4,294,966,974 milliseconds after slot start. That's approximately 49 days, clearly indicating a node that was severely out of sync or experiencing major issues.
However, Lodestar's outlier count was lower than Prysm's - only 22 observations exceeded 30 seconds. The extreme average (4,152 seconds) is driven by these few catastrophic outliers rather than widespread issues.
Caplin showed the best performance with zero extreme outliers and a 2.03 second average arrival time. Teku followed closely with only 4 outliers over 30 seconds and a 2.12 second average.
Block arrival time comparison across consensus clients. Left: Average arrival times. Right: Count of extreme outliers (>30 seconds).
Source: mainnet.fct_block_first_seen_by_node (xatu-cbt cluster)
Time range: February 1, 2026, 21:00-00:00 UTC (3 hours)
Sample size: 192,498 total observations across 9 client implementations
SELECT
meta_consensus_implementation AS client,
COUNT() as count,
AVG(seen_slot_start_diff) as avg_ms,
MAX(seen_slot_start_diff) as max_ms,
countIf(seen_slot_start_diff > 30000) as outliers_30s_plus,
countIf(seen_slot_start_diff > 300000) as outliers_5min_plus
FROM mainnet.fct_block_first_seen_by_node FINAL
WHERE slot_start_date_time >= now() - INTERVAL 3 HOUR
GROUP BY client
ORDER BY avg_ms DESCEthereum continues to finalize without issues. The network is designed to tolerate slow nodes - attestation aggregation and fork choice weighting mean a few delayed observations don't impact consensus.
However, these delays matter for the operators experiencing them. A node taking 13 minutes to see a block is essentially non-functional for validation purposes. These are likely nodes in the process of syncing, experiencing network partitions, or dealing with resource constraints.
The data reinforces the value of client diversity. While Prysm shows these delay patterns, operators running Lighthouse, Nimbus, or Teku experienced significantly better performance during this window.