Arrival time has been my stand-in for PeerDAS bandwidth. It sort of worked, but it was still a timing proxy. A process-level counter now exposes bytes by port, so I expected a clean rising curve with blob count.
That curve exists. It is not remotely uniform.
I called hundreds of thousands of engine_getBlobsV2 rows proof that some execution-client builds did not support the method. That was too clean. UNSUPPORTED was a label added by the collector, not a status returned by the execution client.
This corrects both The Blob Blindspot and engine_getBlobsV2 is still fragmented. The counts in those posts were real counts of rows carrying that label. The interpretation was wrong.
A seven-day freshness filter against Xatu's old blob_sidecar eventstream returned 598 rows. They looked recent only because their event timestamps were in 2033, 2034 and 2040. Every payload and database insertion belonged to July 3, 2025.
This is not Ethereum taking eight years to deliver a blob. Two contributor clocks briefly went feral.
Optimism's July 7 status update was oddly specific: after a brief unsafe-head stall, the sequencer was producing blocks again, but some nodes were not syncing. Ethereum saw another symptom at almost exactly the same time. OP Mainnet's L1 blob batcher stopped posting for 23 minutes and 24 seconds, its longest gap in a scan of 14 complete days.
beacon_api_eth_v1_beacon_blob looks like a blob table until you count it. Across the seven complete UTC days from Jun 26 through Jul 2, it had 5,557,049 rows. The canonical chain had 187,031 blobs in the same window.
That was not a hidden 30x blob burst. It was the same blob commitments being observed over and over by Xatu's Beacon API sentries.
The June 29 sparse-blob day looked like one weird account making a mess. 0x54dd...bcb8 sent 11,784 one-blob transactions at about half a percent full, then disappeared from the next complete day I checked. The uncomfortable part is that the tiny-blob tail stayed behind.
The weird June 18 blob record was not a one-off. On June 29, the same unlabeled address came back with an even cleaner signature: 11,784 type-3 transactions, one blob each, 0.49% filled on average. It produced 31.8% of Ethereum's blobs that day while carrying only 7.5 MB of payload.
Base had a public bad day on June 25. The status page said mainnet block production was unhealthy at 16:03 UTC, sequencing had resumed by 17:51, and the incident was resolved at 19:22. The Beryl maintenance window still went ahead from 18:00 to 20:00.
Correction — 17 July 2026:
UNSUPPORTEDwas a derived RPC-snooper label for a null or non-array V2 result, not proof that an execution client lacked the method. The client/version support interpretation below is wrong. The complete successful-return counts still hold because V2 is all-or-nothing. The correction matches the same requests across the consensus and snooper captures.
The blob data is there.
The Engine API path to fetch it is not equally there.
I screwed up the June blob chart.
The shape was right. The unit was wrong. I divided blob gas by 786432, which is six blobs' worth of blob gas, then called the result "blobs". That means every number in the post was one-sixth of the actual blob count.
June 3 was not 6,408 blobs. It was 38,445 blobs.