I expected the 21-blob blocks to look ugly.

They don't. At least not in the median case.

Correction, 2026-06-19: this post mislabeled six-blob bundle equivalents as blobs. The shape is right, but the y-axis is 6x too low. June 3 was 38,445 actual blobs, not 6,408. I wrote up the correction here: Ethereum's June blob surge was 6x bigger than my chart said.

When Ethereum transitioned to proof-of-stake in 2022, the combination of EIP-1559 burning and reduced issuance made the supply actually deflationary during periods of high activity. You'd see charts showing ETH supply shrinking, treasury posts celebrating "ultrasound money," and a widespread assumption that high network usage would keep issuance in check.

That assumption is dead. The data from the last four months makes it clear.

Every blob you add to a block makes it slightly harder for validators to attest to it on time. This isn't a theoretical concern — it shows up in the data today, at the current limit of 6 blobs per block. When Fulu raises that limit, the cost scales with it.

The mechanism is straightforward. The cost of getting it wrong is less obvious.

Something significant happened to Ethereum four days ago, and it's largely flown under the radar.

On March 2, 2026, between roughly 10:24 and 13:00 UTC, the mainnet experienced its most severe consensus disruption since the proof-of-stake transition. Block orphan rates hit 68%. Validator participation collapsed to zero in at least one epoch. The chain stopped finalizing — not for twenty minutes like the May 2023 incident, but for close to three hours.

This is the third network incident in twelve days.

Transaction receipts are one of those parts of Ethereum that node operators silently carry but rarely talk about. Every full node stores every receipt for every transaction ever executed: gas used, status, and — crucially — every event log the transaction emitted. That accumulates fast.

As of March 2026, Ethereum's full receipt history weighs in at 55.5 GB across roughly 430 days of post-Merge data tracked in EthPandaOps' xatu dataset. Growing at about 1.65 GB per day, it's manageable. But in early December, something broke that trend spectacularly.

Every Ethereum block has the same skeleton: a list of transactions, ordered from position 0 to whatever the builder packed in. Naively, you'd assume position 0 belongs to the highest-paying user — priority fee sorts everything. But that's not what the data shows.

Half of all position-0 transactions pay zero priority fee. And paradoxically, they are the safest transactions in the entire block — reverting at 0.027%. The tail of the block (positions 200-400) reverts 60× more often.

There are 842,000 transactions sitting in the Ethereum mempool right now that have been there for more than 24 hours. Most people assume they're stuck because gas fees went up. That's wrong.

69% of them — 582,000 transactions — are mathematically impossible to include. Not "too expensive to bother with," but literally incapable of being mined at any point in the future at their current pricing.

And inside that group, there's a quieter disaster: 9,436 wallets are in a nonce death lock, where one underpriced transaction from days ago has frozen every subsequent transaction the address ever tried to send.

Every MEV dashboard focuses on the same number: the execution layer bid that the winning builder pays the proposer. It's tracked obsessively. Tournaments are run around it. Entire firms exist to maximise it. And for 93% of blocks proposed on mainnet right now, it's the smaller of the two income streams the proposer receives.

The other stream — the consensus layer's attestation inclusion reward — sits quietly in the background, never shown on dashboards, never cited in "MEV revenue" charts. It's roughly four and a half times larger than the median MEV-boost payment.

The blob count limits on Ethereum have always been embedded in the consensus spec. Pre-Fulu, both the target and maximum blobs per block were hardcoded: currently 3 target / 6 max (post-Dencun). Changing them required a hard fork.

EIP-7742 changes that. From Fulu onward, the consensus layer sends the target and max as fields in the ExecutionPayloadHeader. The execution layer reads them and applies them dynamically. No recompile. No fork vote required for the limit itself — only for the mechanism that sets it.

This is a real change to how the blob fee market works.