block_gossip sounds like the clean block-arrival clock. Most of the time it is. Then Caplin shows up with canonical block roots arriving eight minutes after the slot started, which is not how blocks propagate on Ethereum unless something has gone very wrong.

Nothing went very wrong.

Storage diffs sound like state growth. Sometimes they are just a tiny piece of state getting hammered over and over. Last week one contract labelled Oracle changed the same three already-nonzero storage slots 117,150 times, spread across 39,050 transactions. By June 19 it was showing up in about five out of six canonical blocks.

The per-contract ERC-20 transfer leaderboard looks sane for about three rows. USDT is first, USDC is second, WETH is third, and then individual tokens whose names look like USDT, USDC, and ETH start showing up. Aggregated as a family, those lookalikes belong above WETH.

From June 17 through June 23 UTC, 19 Unicode lookalike contracts in the top-50 ERC-20 event sources emitted 4,858,242 unique Transfer logs. Real USDC emitted 4,929,166. The lookalikes got almost the same event count from 47,703 transactions, while USDC needed 1,596,999 transactions.

The top ERC-721 transfer source last week was not a mint everyone suddenly cared about. It was a mirror contract.

From June 17 through June 23 UTC, ORE404Mirror emitted 273,448 unique ERC-721 Transfer logs from 740 transactions. That made it the busiest ERC-721 event source in Xatu's new execution tables, more than 7x the next contract by deduped event count. The awkward part is that the verified source says exactly what it is: contract ORE404Mirror is DN404Mirror.

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 a BALANCE opcode 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.