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.

Base had a public bad day on June 25. The status page said mainnet block production was unhealthy at 16:03 UTC, sequencing had resumed by 17:51, and the incident was resolved at 19:22. The Beryl maintenance window still went ahead from 18:00 to 20:00.

A 65,534-block Ethereum reorg did not happen last week. Caplin still said it did, at least through the Beacon API chain_reorg event stream.

Erigon 3.5.0 landed with a very good headline: parallel block execution is on by default. That should make Ethereum block validation feel less serial, at least where the workload and configuration let it pay off.

The builder-class telemetry I checked had the opposite shape. Two observed Erigon 3.5.0-dev-8b4c6990 nodes processed the same 7,174 mainnet payloads as the other eip7870 builder nodes. Giving every implementation its fastest observed node in each slot, Erigon's median was 283 ms. The fastest non-Erigon observation in each slot had a 24 ms median; Reth's own per-implementation median was 25 ms. Erigon won one fastest slot.