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 failed bucket 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 as validation failed 11–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'.

Rocket Pool's rpl_staked event looks like it fell off a cliff at exactly the wrong time. The last decoded stake event in mainnet.int_rocketpool_node_event was 2026-02-17 23:20:23 UTC. The first decoded megapools started about 40 minutes later, on Feb 18, and the withdrawal side kept moving for months.

That does not mean "nobody staked RPL after Saturn." It means the old decoded stake-event surface is a bad post-Saturn RPL-staking ledger unless you know what changed.

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.

beacon_api_eth_v1_proposer_duty looks block-ish if you only read the name. It has slot, epoch, proposer_validator_index, and a timestamp from the client that fetched it. That is enough rope to build a very wrong proposed-block counter.

The table is not a block feed. From Jun 27 through Jul 3 UTC, it had 1,491,952 raw rows for 50,400 scheduled slots, and the duty for the last slot in each epoch first appeared about 6m12s before that slot could produce a block.

I owe this one a correction. In February I wrote that Ethereum was carrying 296 GB of state. That was the value of mainnet.fct_execution_state_size_daily.total_bytes, but it was not the component total I described in the post.

On the same Feb 26 row, the exposed account, account-trie, contract-code, storage, and storage-trie byte columns add up to 430.9 GB. Storage trie bytes alone were 220.8 GB, so my old sentence saying "296 GB total" while also talking about trie bytes as part of that total was internally broken.

Type-4 transactions are easy to count and easy to overread. From Jun 20 through Jul 3 UTC, Ethereum had 257,388 deduped type-4 transactions, which was only 0.824% of all transactions in the same blocks. That sounds like a small EIP-7702 adoption number until you look at the gas: one address labelled Poisoner and a pile of plain ERC-20 transfer(address,uint256) calls consumed 86.5% of type-4 gas.

That is the trap. transaction_type = 4 tells you the envelope is EIP-7702's set-code transaction type. It does not, by itself, tell you this is a clean smart-wallet action, a user operation, or even something interesting at the authorization-list layer.

Some table names quietly lie to you. canonical_execution_address_appearances has relationship rows called erc20_transfer_from and erc20_transfer_from_to, which sounds like it should cover both sides of a token transfer. On July 1, it did something simpler and uglier: it pointed at the sender twice.

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.

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.