I expected Ethereum's shortest-lived storage to be token-account churn: balances created, spent, and gone. USDC and USDT do show up, but neither contract was first. LayerZero's ReceiveUln302 created 52,161 storage slots and deleted them in the next execution block.

Its EndpointV2 added another 24,163. Together, those two contracts made 76,324 of Ethereum's 212,618 adjacent-block storage lifecycles, or 35.90%, across 14 complete days. This was not random garbage. It was a cross-chain message waiting room being filled, checked, moved, and cleared.

I went back to March's zombie-state post because its biggest number had started to smell wrong. Forty-one million XEN storage slots supposedly woke up in three days, then almost nothing. That was not an Ethereum event. It was a model backfill that I mistook for block time.

The corrected 55-day count is 3,833,522 reactivation rows, not 97,466,839. XEN accounts for 2,142,144, not 48,302,239. The alleged Dec 20-22 spike is 225,421 XEN rows, not 41,816,729.

aggregation_bits looks like a field you can group across clients. I tried that, and one gossip payload turned into three strings.

The participants had not changed. The Xatu emitter path had. In one hour, 41,441 of 247,296 content-derived message IDs carried more than one stored aggregation_bits value, while every other parsed attestation field agreed.

The aggregate-and-proof table had three encodings for a real bitlist. Its ordinary-attestation sibling manages something stranger: the column is present, but the gossip object has no bitlist. In 15 minutes, 1,960,559 message IDs still split into two values because one emitter spells empty as "" and another spells it 0x.

Xatu v1.22 added an archive for raw Gossipsub wire bytes. The table uses content-derived message IDs and a replacing merge tree, so it sounds safe to treat count() as a unique-message count.

It is not. In a two-hour mainnet window, 35,806 of 197,889 aggregate-and-proof message IDs survived twice. The second row appeared when the same content ID crossed a 12-second wallclock-slot boundary.

Arrival time has been my stand-in for PeerDAS bandwidth. It sort of worked, but it was still a timing proxy. A process-level counter now exposes bytes by port, so I expected a clean rising curve with blob count.

That curve exists. It is not remotely uniform.

validation failed sounds like a verdict on the bytes. It is not that clean.

Across 668 PeerDAS data-column rows carrying that libp2p reason, three exact message IDs had already been delivered near slot time. Other observers logged them as duplicates, then one observer rejected the same ID 11 to 15 minutes later.

I called hundreds of thousands of engine_getBlobsV2 rows proof that some execution-client builds did not support the method. That was too clean. UNSUPPORTED was a label added by the collector, not a status returned by the execution client.

This corrects both The Blob Blindspot and engine_getBlobsV2 is still fragmented. The counts in those posts were real counts of rows carrying that label. The interpretation was wrong.

A libp2p connection can stay up while one of its Gossipsub mesh links is torn down two seconds after it is added. On July 15, the row-weighted median between a Tysm observer logging GRAFT and then PRUNE for the same peer and topic was 1.824 seconds.

I called 38.6% of Ethereum gas a permanent-storage bill in February. That sentence was wrong. The table was a research allocation model, not a meter attached to physical state growth, and a quarter of the SSTORE gas it put in state_growth came from transactions that added no net-new storage slot at all.