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."

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.

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.

I almost talked myself into a fake MaxEB panic: sync committee selection is stake-weighted, attestation rewards scale with effective balance, so maybe sync committee rewards accidentally scale like stake squared.

They don't. In the first usable canonical_beacon_sync_committee_reward window I checked, validators with 1024+ ETH effective balance were 0.67% of active validator indices, 26.45% of active effective stake, 26.20% of observed sync committee member-slots, and 26.36% of sync committee rewards. The scary stake-squared model would put them at 91.56%.

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.

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.