I expected finalized_checkpoint to be boring.
It has four useful fields: block, state, epoch, and execution_optimistic. The obvious read is that block is the finalized checkpoint block root and state is the finalized checkpoint state root.
For six clients, that is exactly what shows up.
For Lodestar and Grandine, it is not.
The biggest validators are not the weird ones this time.
I expected the MaxEB performance chart to be boring: larger effective-balance validators are mostly run by serious operators, so they should miss less and vote cleaner. That was true for the 1024-2048 ETH bucket. It had the best liveness in the sample.
Then the bucket below it fell off a cliff.
The new Xatu execution tables are exactly the kind of thing I like: raw enough to be dangerous, tidy enough to query without crying. Then I opened canonical_execution_native_transfers and got a very silly-looking leaderboard.
USDT was the top native-transfer recipient.
I opened the new contract-creation table expecting the usual factory soup: account abstraction wallets, Uniswap pools, NFT leftovers, random deployer spam. XEN was sitting in the middle of it again, quietly copying the same tiny contract over and over.
Not metaphorically tiny. Forty-five bytes.
I had been reading the gas-limit signalling table too literally.
It shows a stubborn 30M/36M tail, even though Ethereum's block headers have been sitting around 60M gas for months. I used to describe that tail as validators still signalling old limits. That was too generous. A chunk of it looks like relay-registration fossils.
A state write is not one write.
That sounds obvious if you have stared at Merkle Patricia tries long enough. It still hits differently when you count it block by block.
Across seven complete UTC days, the median Ethereum block made 1,329 logical state writes and rewrote 6,930 MPT nodes.
About 5.26 trie nodes per logical write. Every block. Quietly.
The naive MaxEB question is easy to ask and surprisingly easy to answer with data.
If one validator can carry 2,048 ETH, does it get one sync committee ticket or something closer to sixty-four?
The answer on mainnet is blunt: sync committees follow stake, not validator count.
A stale execution peer is not always a node that forgot the latest fork.
Sometimes it is a modern client binary sitting at the mainnet genesis block and politely telling the world it is ready for Homestead.
Across seven complete UTC days, 201 of 1,444 discovered mainnet execution node IDs advertised old fork IDs. 164 of those had the old Frontier fork ID, 0xfc64ec04, with next = 1150000.
That is not "slightly behind."
That is genesis.
PeerDAS has a tiny ENR field called cgc.
It is supposed to say how many custody groups a peer has. The boring answer would be: most peers advertise the minimum, a few advertise more, and probe results roughly follow that.
The boring answer was wrong.
A lot of Ethereum code still says SELFDESTRUCT.
That word is now a trap.
After EIP-6780, SELFDESTRUCT only deletes code and storage when the contract was created in the same transaction. Older contracts can still send their ETH balance to a beneficiary, but the account does not get wiped.
So I checked how often the opcode is still real deletion.