A voluntary exit has an epoch field, and it is very tempting to read that as "the epoch this validator exited." That is wrong in exactly the way that produces fake history. In the last 31 complete UTC days, 75.4% of mainnet voluntary exits carried an epoch more than 30 days old, or epoch 0.
The exit happened when the message landed in a canonical block. The message epoch was just the point from which the signature became valid.
MaxEB made 2,048 ETH validators possible. The first big consolidation batches are not aiming all the way there. They keep landing around 1,920 ETH, which is sixty old 32 ETH validators packed into one key with some reward dust on top.
Counting pending deposits used to be close enough to counting future validators. One queue entry, 32 ETH, one validator. That shortcut is now broken in the queue itself, not just at the deposit contract.
In the latest mainnet pending-deposit snapshot I checked, the queue had 37,334 deduped positions carrying 2.807M ETH. By position count it still looked boring: 81.4% of positions were exact 32 ETH deposits with 0x01 withdrawal credentials. By ETH, the story flipped. Large 0x02 compounding deposits were only 5.6% of positions, but 60.9% of the queued ETH.
block and head sound even cleaner than block_gossip. A block event says the beacon node saw a block. A head event says fork choice moved to it. If those rows show up hours after the slot started, the first question should not be "did Ethereum propagate blocks hours late?" It should be "what denominator did I just use?"
The denominator was the row.
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 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.