Stale Parent Block Proposals
Question
How often do Ethereum proposers build on a genuinely stale parent (not just missed slots), and do solo stakers, Rocket Pool, or Lido CSM operators have disproportionately high stale parent rates?
Background
Every beacon block references a parent_root – the block it builds on top of. In the normal case, a proposer builds on the immediately preceding canonical block (parent distance = 1). When a proposer's node is behind the chain tip, the proposed block will have a parent distance greater than 1.
A parent distance of 2 is usually benign: the previous slot was simply missed, and the proposer correctly built on the most recent canonical block. But when canonical blocks exist between the parent and the proposed block, the proposer genuinely missed them – their node was out of sync. These "truly stale" blocks are almost guaranteed to be orphaned because fork choice will never prefer them over the canonical chain's accumulated attestation weight.
Methodology: For each block in fct_block (both canonical and orphaned), we self-join on parent_root = block_root to find the parent block's slot, then compute slot - parent_slot as the parent distance. To distinguish truly stale blocks from benign missed-slot cases, we check whether any canonical blocks exist between the parent slot and the proposed slot. If none exist, all intervening slots were missed and the proposer built correctly. If canonical blocks exist in between, the proposer was genuinely behind.
The block proposed in Slot 4 built on Slot 1 instead of Slot 3, giving it a parent distance of 3. Since canonical blocks exist in Slots 2 and 3, this is a truly stale parent reference.
Investigation
Parent Distance Distribution
View Query: parent_distance_distribution
The relationship between parent distance and orphan rate is stark:
- Distance 1: 1.35% orphan rate (normal)
- Distance 2: 2.17% orphan rate – but 98.4% of these are benign (the previous slot was simply missed)
- Distance 3: 34% orphaned
- Distance 4: 83% orphaned
- Distance 5+: 100% orphaned – no block with parent distance
>=5 has ever survived into the canonical chain in this 3-month window
Is the Truly Stale Rate Changing?
View Query: parent_distance_daily
The stacked bars show canonical truly stale blocks (blue) and orphaned truly stale blocks (red). The Prysm Fusaka mainnet incident on December 4, 2025 caused a clear spike in truly stale proposals, as Prysm nodes experienced resource exhaustion and fell behind the chain tip. Since mid-December, the rate has settled back to baseline.
Entity Group Comparison
View Query: parent_distance_entity_summary
With missed-slot cases excluded, Solo Stakers still have the highest truly stale parent rate. The p95 distance column reveals tail severity: Solo Stakers' stale blocks tend to be much further behind the chain tip than professional operators.
Distance Distribution by Entity
View Query: parent_distance_distribution_by_entity
The chart shows all blocks with parent distance > 1, broken down into total blocks (faded) and truly stale blocks (solid). The log scale reveals the tail – select different entity groups to compare how far behind stale proposers typically are.
Weekly Trend by Entity Group
View Query: parent_distance_weekly_by_entity
The Prysm Fusaka incident (week of December 1, 2025) is clearly visible as a spike across all entity groups. Solo Stakers were disproportionately impacted – likely because solo operators running Prysm were slower to apply the emergency fix compared to professional node operators who could respond faster.
Top Individual Entities
View Query: parent_distance_top_entities
Takeaways
- Parent distance
>=5 means certain death: 100% orphan rate. At distance 3, a third are orphaned. At distance 4, over 80% - Most distance-2 blocks (98.4%) are benign – the previous slot was simply missed. Only 1.6% represent a genuinely stale proposer
- Solo Stakers have the highest truly stale parent rate, with a fatter tail of deeply stale blocks (check the p95), suggesting real infrastructure/sync issues
- Rocket Pool and Lido Professional perform better, with Lido CSM lowest (small sample)
- The Prysm Fusaka incident (Dec 4, 2025) caused a clear spike across all groups. Solo Stakers were hit hardest and recovered slowest – likely due to slower patching of the emergency fix
- The gap between solo and professional operators suggests that infrastructure quality (faster sync, better peering, redundant nodes, faster incident response) meaningfully reduces stale parent risk