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.
Teku 26.7.0 landed with a very specific operational note: QUIC p2p is enabled by default, on UDP port 9001 for IPv4. That is the kind of release-note claim that should leave a mark in the peer records if the release is actually visible on mainnet.
It did, but the shape was not "Ethereum just got QUIC." Most of the consensus ENRs I saw already had a quic port. Teku was the laggard.
canonical_beacon_validators looks like the obvious table to count validators. It is, but only after you pick one epoch. If you skip that step, you can manufacture half a billion validator rows in a day.
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."
canonical_beacon_state_pending_partial_withdrawal looks like a tidy queue table. It is not a validator count, and it is very much not a daily intake table. In the latest mainnet snapshot I checked, the queue had 87 positions, 81 validators, and 1,457.9 ETH pending.
canonical_execution_four_byte_counts sounds like the table you reach for when you want to count function calls. That is exactly how to get lied to.
I expected a selector leaderboard. What I found was one row per transaction, with the noisiest selector inside that transaction winning the row. Useful, but only if you do not read the name too literally.
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.
canonical_execution_nonce_reads sounds like it should tell you who is using nonces. It mostly tells you which accounts execution had to touch. In the seven complete UTC days from June 23 through June 29, the table had 71.7M nonce-read rows. 31.0M of them, 43.2%, read nonce = 1.