55% of all storage slots ever written on Ethereum are created once and never touched again — that's state growth, not churn. A new deep-dive from ethresear.ch, covering every block from genesis to block 24,870,000, dissects how state is actually read and written, and the numbers are brutal for anyone who thinks Ethereum can keep treating all state equally.
Write Traffic Is Growth, Not Churn
Over Ethereum's entire history, slot write events total 9.20B. Updates (x→y) account for 66.4% of events, but the lifecycle data tells a different story. Across any 30-day window, about 53.3% of written slots are pure creations (0→x) that never get modified or deleted in that window. At a 365-day window, that share climbs to 55.4%. Most slots are born and then forgotten.
Deletions hit 8.3% of all slot write events ever, meaning a third of all slots ever created have been deleted. But the vast majority of writes are just adding new state, not replacing old state. The active write set is a tiny fraction of the live state: at a 30-day window, only 2.82% of all live slots are written. At 365 days, that creeps to 24.17%.
Read Traffic Is Mostly Existence Probes
Counted per distinct slot in the read-only set (R), 82.5% of slots read but not written in a 30-day window return zero. These are empty-slot probes — callers checking "does this contract storage slot exist?" without ever writing. The share of zero-only reads grows as the window widens, hitting 92.6% at 365 days. So most read-only traffic is noise.
By event count, populated reads dominate (69.9% of all SLOADs hit a nonzero value) because a tiny hot set of popular slots gets hammered. Weighted by distinct objects, empty probes are the majority. The warm set that matters for gas is the write set plus the small populated read set (R+). Adding populated reads only increases the warm slot set by 0.21 percentage points at 30 days, or about 0.26% of total state.
Access Is Extremely Concentrated
The top 1% of read accounts captures 96% of read accesses at a 30-day window, and 98.7% at 365 days. For slots, the top 1% grabs 83.8% at 30 days, 87.7% at 365 days. The head is dominated by stablecoins (USDC, USDT), WETH, and DEXes (Uniswap V4 PoolManager is #8 in most accessed accounts). Block builders like Titan, BuilderNet, and beaverbuild rank high because every transaction credits the fee recipient, but the real hot contracts are tokens and lending protocols.
Slot-level concentration is driven by the same contracts: USDT and USDC storage slots are accessed 1.31B and 799M times respectively in a 365-day window, followed by WETH (332M), XEN (317M), and Uniswap V4 PoolManager (133M). A handful of applications account for nearly all storage traffic.
The 30-Day Tiering Sweet Spot
EIP-8188 adds a last_written_block metadata field; EIP-8295 builds a tiering scheme on top that prices recently-written state cheaply (Active) and long-dormant state expensively (Inactive). The counterfactual analysis models this with rolling windows.
At a 30-day window, 94.1% of slot update SSTOREs are already warm — meaning the slot was written earlier in the same window. For accounts, it's 97.0%. That drops the Inactive premium to only ~3-6% of updates. Even a 1-day window covers 85.2% of slot updates and 92.0% of account updates — because the hot set is written multiple times within a single day.
Going from 30 days to 365 days buys just +3.6pp of slot update coverage (94.1% to 97.7%), but the Active set balloons from 2.82% to 24.17% of live slots — roughly 9× more state kept warm for negligible extra gas coverage. The sweet spot is around 30 days: capture nearly all the gas-relevant activity while keeping the cheap tier tiny.
The analysis makes one thing clear: Ethereum's state growth is a one-way ratchet, and any design that treats all state as equally live punishes users for the chain's age. A write-age tier built on EIP-8188 metadata would let Ethereum scale its state sustainably by making the dormant tail pay its real cost.
Source: The Anatomy of Ethereum's State Access
Domain: ethresear.ch
Comments load interactively on the live page.