A libp2p connection can stay up while one of its Gossipsub mesh links is torn down two seconds after it is added. On July 15, the row-weighted median between a Tysm observer logging GRAFT and then PRUNE for the same peer and topic was 1.824 seconds.
mainnet.fct_data_column_availability_by_slot_blob has both blob_index and probe_count, which makes summing the latter feel safe. It is not. Across 14 complete UTC days, the source slot/column table held 63,597,380 observation units; the blob-level table summed to 335,651,250 probe_count units because it copied each column result once for every blob in the slot.
earliest_available_slot sounds like one clean boundary. It is actually two storage policies squeezed into one integer.
At noon UTC on July 10, I found 14,598 near-head observer-peer pairs in Xatu Status v2 telemetry. 83.00% advertised at least the old five-month block-history window, while 3.96% advertised less than PeerDAS's 18.2-day sidecar window. The split was aggressively client-shaped.
PeerDAS now has two places where a peer can tell you how many custody groups it claims to serve. I expected the live metadata handshake to clean up the old cgc=0 ENR hole. Instead it hid it.
mainnet.fct_data_column_availability_by_slot looks like the table you would use to ask whether PeerDAS custody probes are succeeding. It has availability_pct, success_count, missing_count, failure_count, and a column called probe_count. I used it that way first, and it told me something too clean: 100.00% availability for seven complete UTC days.
That is not the active custody-probe success rate. It is mostly the gossipsub sidecar observation stream wearing an availability-shaped name.
beacon_api_eth_v1_events_data_column_sidecar has a very clean-looking trap. It has a column_index, and it has kzg_commitments_count. If you sum that field, you are not counting blobs. You are counting the same block-level commitment list once per data column, and then again for every observer row that emitted the event.
Two days ago I wrote that Nimbus v26.6.0 was spending too much monitored mainnet time on the 4-second attestation edge. Nimbus v26.6.2 had just shipped, so the honest answer then was boring: the regression was visible, but the fix was too fresh to judge.
There is enough post-release data now for a first check. It is not a clean victory lap. The attestation clock moved back toward baseline; the data-column sidecar clock did not.
Nimbus cut v26.6.2 this morning with a blunt note: it "mitigates regressions in attestation performance and bandwidth usage in v26.6.0." That is exactly the kind of release note that is easy to nod at and move past. I wanted to know whether the monitored mainnet data had a shape behind it.
It did.
PeerDAS has a tiny ENR field called cgc.
It is supposed to say how many custody groups a peer has. The boring answer would be: most peers advertise the minimum, a few advertise more, and probe results roughly follow that.
The boring answer was wrong.
I expected the 21-blob blocks to look ugly.
They don't. At least not in the median case.