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.
The libp2p control tables had one of those numbers that looks fake enough to be interesting: 3.23 billion PRUNE rows on June 25, from the mainnet Gossipsub sample. If you read that as "three billion peers got pruned", the table is lying to you.
It is not a peer count. It is not a rejected-message count. It is a control-plane row surface, and on that day it expanded much faster than the observed peer set did.
Clarification, 2026-07-18: Even the
validation failedbucket is an observer-time result, not an intrinsic label on the message. A later exact-ID check found three data-column messages that had been delivered near slot time, then appeared asvalidation failed11–15 minutes later. The follow-up has the matched delivery, duplicate and sidecar rows.
libp2p_reject_message sounds accusatory. It looks like the table you would count if you wanted bad gossip, invalid messages, or peers doing something wrong.
That is almost exactly how to overread it. In the seven complete UTC days from Jun 28 through Jul 4, the table had 31,027,943 mainnet rows. Only 247 of them were reason = 'validation failed'.
IDONTWANT sounds like the clean negative image of IWANT: one peer asks for a message, another says please do not send it. The row counts even make that story tempting. On July 1 UTC, Xatu's mainnet libp2p sample had 56.2M IWANT rows and 48.8M IDONTWANT rows.
That neat story breaks as soon as you dedupe the message IDs.
libp2p_rpc_meta_control_ihave is a beautiful foot-gun. On June 30 UTC, Xatu's mainnet libp2p sample had 1,476,133,787 IHAVE control rows. That was not 1.5 billion blocks, attestations, or delivered gossip messages. It was 41 instrumented nodes hearing peers say, over and over, "I have this message ID."
PeerDAS — EIP-7594's data availability sampling system — has been live on Ethereum mainnet for over 30 days. All 128 column subnets are active, and the data is arriving: 10,956 out of 10,958 slots in the last 48 hours had every single column propagate within 12 seconds. That's 99.98% completeness. The protocol is working.
But there's something nobody seems to have noticed: column index 0 arrives 156 milliseconds faster than column index 101. The correlation between column index and median propagation time is 0.82. And it's been this way, consistently, for seven consecutive days.