EIP-8347 changed one file format on August 20. The new format is brutally easy to size: 24 bytes per account, then 32 bytes per live storage slot. Point that arithmetic at mainnet on August 19 and the file comes out at 62.25 GB.
Roughly 40.7 GB of it maps to slot keys that had not been read or written in twelve months.
I thought the missing corner of Ethereum's storage-lifecycle table would be ordinary transaction-local scratch space. It wasn't. Across August 5-18, 166,386 contract-slot cycles started at zero, became nonzero, and returned to zero before the block ended. USDC and USDT alone made 44,355 of them.
Ethereum added just under two million net storage slots on August 16. XEN Crypto was responsible for 1,464,993 of them.
That came from 5,747 transactions, only 0.31% of the day's transaction count. They used 26.3% of execution gas and left behind 73.7% of the net slot growth. Under the constants in EIP-8037, the XEN storage writes alone backcast to 149.25 billion state gas, or 69.2% of that day's 50% state-gas target at the observed block limits.
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.
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.
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_bytesas "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.