The report instrumented 123 Beacon-chain nodes across 27 countries, 29 in controlled data centers, and 94 in residential settings to track the “New Head” event. This is a timestamp recorded when a client declares a block and its blobs the new chain tip.
The benchmark requires 66% of peers to reach New Head within four seconds, or the block risks being orphaned.
Charts covering 50,025 slots through May 28 show home-user nodes accepted locally built solo-staker blocks in under four seconds 99.5% of the time, with only a handful of outliers.
Regression across block size and arrival time projects that home nodes could tolerate up to 14 blobs before brushing the deadline, well above the nine-blob cap.
The report concluded that “home users were able to support nine blobs,” validating pre-fork modeling that assumed bandwidth sensitivity at the network edge.
The same regression trimmed safe capacity to 10 blobs, leaving a narrow margin but still clearing the live 6/9 envelope.
The report noted that a higher gas cap would further tighten the window, reinforcing community calls to halt future gas limit increases until peer-to-peer data availability sampling (PeerDAS) ships in the subsequent Fusaka release.
About 91% of main-chain blocks route through MEV-Boost relays, which insert a bid-acceptance round-trip between proposers and builders.
Relay-sourced blocks reached New Head marginally slower, with home nodes registering 97.1% inside four seconds versus 99.5% for locally built blocks.
A distribution plot attributes the tail to relays that delay header broadcasts as part of competitive timing strategies. Worst-case 60 million-gas simulations indicated a safe relay capacity of five blobs, but ethPandaOps expects relays to adjust once the competitive landscape penalizes late delivery.
Additionally, developers plan to shift from proposer-side blob propagation to PeerDAS under the Fusaka hard fork.
EthPandaOps stated that the team is “heads-down” in integrating PeerDAS, which should reduce per-block bandwidth and open up room for higher gas limits and larger blob counts once deployed.
The report concluded that the telemetry from the first week of Pectra shows the 6/9 blob schedule functions as designed, giving client teams room to focus on Fusaka’s data-availability upgrades without immediate pressure to revisit bandwidth ceilings.
