I keep seeing the deposit contract treated like a 32 ETH counter. That shortcut broke.
On June 23 UTC, Ethereum had 51 deposit events of exactly 1,920 ETH. They were only 12.9% of the day's deposit events, but they carried 97,920 ETH, or 82.7% of the ETH that hit the deposit contract.
Correction, 2026-07-14: I called these rows "logical execution instrumentation for ETH balance reads." The count was right, but the noun was wrong. Xatu gets this table from Cryo's projection of Geth's
prestateTracer, so each row is a transaction-account prestate record, not aBALANCEopcode or repeated-read counter. The fee-recipient one-row-per-transaction result survives. I wrote up the correction here.
USDT was not the hottest address in the balance-read table.
I expected the usual suspects: USDT, USDC, WETH, routers, precompiles, some unlabeled contract that every block touches. They are all there. But the biggest line in the one-day sample was a builder fee recipient, because the execution path records a balance read against the block author once per transaction.
That sounds obvious after you see it. It was not obvious from the table name.
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.