Ethereum's consensus spec just made QUIC the mandatory, preferred libp2p transport. Xatu's connection rows show that QUIC was already doing plenty of work, but almost entirely in one direction.
Across June 27 through July 10, the Tysm-instrumented mainnet sample recorded 6,884,989 outbound UDP/QUIC session opens, or 43.56% of outbound opens. The inbound side had 88. That is 0.0036% of 2.43 million inbound opens.
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.
Two days ago I wrote that most observed libp2p disconnect sessions lasted one second. The number was right. The mental picture it invites is not.
Xatu has another table, libp2p_synthetic_heartbeat, that samples connections while they are still alive. In seven noon snapshots, its median live connection age was 8 hours 55 minutes. The disconnect table's median was still one second.
libp2p_disconnected sounds like a peer-churn table. I would not use it that way.
Across the latest seven complete UTC days, Xatu recorded 8,874,848 mainnet disconnect rows from 41 observer labels. Those rows covered 23,820 remote peer keys, but the median observed session lifetime was only one second. 57.55% of the rows ended inside ten seconds.
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.
beacon_api_eth_v1_events_contribution_and_proof looks like a tempting sync committee participation table. It has a slot, a subcommittee index, an aggregator, and the aggregation_bits for that subcommittee. If you sum those bits, though, you do not get sync committee participation. You get the same vote surface counted again and again.
The previous type-4 post left one obvious loose end. The labelled Poisoner target was the gas-heavy part of EIP-7702's type-4 surface, so I half-expected it to be private orderflow or at least hard to see before inclusion.
It was the opposite. From Jun 30 through Jul 6 UTC, Xatu saw every one of the 31,565 canonical type-4 transactions sent to that target in its mempool table. The barely visible bucket was the much smaller executeBatch tail.
beacon_api_slot sounds like the table you would reach for when you need a slot count. That is the trap. On Jul 5 UTC, mainnet had 7,200 scheduled slots and 7,165 canonical blocks. The raw beacon_api_slot table had 2,550,257 rows and 712,240,161 attestation-count units.
That is not Ethereum having 712 million canonical attestations in one day. It is an observer rollup doing exactly what the schema says, with a name that invites lazy queries.