Correction, 2026-07-16: canonical_execution_storage_reads is a transaction-slot prestate set, not an SLOAD or repeated-read counter. The fixed USDT slots really were present across the sampled transactions, but the table cannot support the claims of five million SLOAD executions, 6,300 gas per transfer or 2.7 billion gas per day. I am retracting those operation and gas estimates. The source audit and 519-transfer batch check are here. The original text remains below for the record.

Buried in the USDT contract source code is a comment that reads: "additional variables for use if transaction fees ever became necessary." Beneath it: basisPointsRate = 0 and maximumFee = 0. Both initialized to zero. Never changed. The fee mechanism was coded in 2017 in case Tether ever wanted to charge for transfers. They never did.

But the code that reads those variables runs on every USDT transfer. And USDT transfers happen in virtually every Ethereum block.

Every 12 seconds, your execution client gets a new block and has to tell the consensus layer: valid or not. The call is engine_newPayload, and how long it takes determines how fast your validator can attest to the new head.

That window matters. A faster EL client means earlier head votes, better attestation accuracy, and more flexibility in how you run your validator. The timing game, MEV extraction, and late block handling all happen inside this gap.

So which execution client is fastest? The data is messier than the win-rate leaderboards suggest.

Correction, 2026-07-04: the dormant-storage-slot analysis in this post still stands, but the headline byte count was wrong for the sentence I wrote. I used mainnet.fct_execution_state_size_daily.total_bytes as "total state," then described storage-trie bytes as part of that total. The same Feb 26 row's exposed byte components sum to 430.9 GB, not 295.9 GB. I wrote up the correction here: The state-size total I used was not the total.

Every full Ethereum node is currently lugging around 430.9 GB of exposed state-size components. Every account, every contract, every storage slot, and the trie nodes wrapped around them. Sync a fresh node and you're downloading all of it. Run a node continuously and you're holding all of it in your database, forever.

The uncomfortable truth: the vast majority of that state is dead. It hasn't moved in over a year. The addresses are abandoned, the contracts are deprecated, the protocols are gone. The data just... sits there. In every node on the network.

Ethereum's block gas limit doubled in 2025. Not through a hard fork. Not through a governance vote. Through three coordinated waves of validators updating their configuration files.

The limit went from 30 million to 60 million gas—a 100% increase in block capacity—between February and November 2025. Each wave moved faster than the last. The final surge, from 45M to 60M, took just 22 hours.

Ethereum had 660 chain reorganizations in the last 30 days. That's a 0.31% reorg rate across roughly 216,000 slots — normal background noise for a live PoS network.

But here's something nobody talks about: if you ask Lighthouse how deep those reorgs were, you'll get a completely different answer than if you ask Prysm. Same event. Same block hashes. Different depth. Every single time.

One validator missing an attestation isn't a crisis. A few hundred validators missing 1 in 8 attestations, every slot, for three months straight — that's a different story. And it's concentrated in a way that the aggregate participation numbers don't show.

The xatu dataset tracks missed attestations at the entity level. When you sort by miss rate, a clear hierarchy emerges — and a handful of operators sit far outside the expected range.

There's a counterintuitive pattern buried in Ethereum's block-building data: the most valuable blocks — the ones where MEV extractors collect the most ETH — consistently contain fewer transactions than ordinary blocks.

Not slightly fewer. Significantly fewer.

A block worth 0.2–1 ETH in MEV carries, on average, 185 transactions. A normal low-MEV block carries 293. That's 108 fewer transactions — a 37% drop from peak — in a block that everyone in the market fought hardest to produce.

Correction — 17 July 2026: I misread Xatu's derived UNSUPPORTED collector label as a response from the execution client. The snooper applies that label to a null or non-array result, while V2 permits null for missing or pruned blobs, syncing, and other inability to serve the complete request. The client-support, version-upgrade and performance conclusions below are not supported by these rows. I also attributed V2 to Pectra; it is specified in the Osaka execution fork paired with Fulu. The full correction reproduces the same calls across both capture paths.

One month after Pectra went live, roughly 44% of all Nethermind validator nodes are rejecting a blob retrieval call that was introduced in that very fork. Every other major execution client has mostly fixed this. Nethermind hasn't moved.

This is the data on what's happening, why it matters, and where the fault line sits.

Most validators proposing a block right now will earn about 0.011 ETH. That's the median. But the mean is 0.050 ETH — more than 4× higher. The reason the mean is so detached from the median tells you everything about how staking rewards actually work.

Over the 30 days ending February 26, 2026, there were 200,963 MEV-Boost blocks on mainnet. I deduped them by taking the highest bid per slot across all relays. Here's what I found.

Each blob on Ethereum costs the same regardless of how much data you actually put inside it. The slot doesn't know if you packed all 131,072 bytes or left 99% empty. You pay either way.

That flat pricing creates a question that hasn't been answered cleanly: how efficiently are rollups actually using the space they're buying? The answer turns out to span an enormous range — from 100% fill all the way down to a rollup that's posting the same completely empty blob, over and over, every block.