11 posts tagged with "state"

A contract address can hold ETH before it has bytecode. That sounds like EVM trivia until a gas proposal has to decide whether deploying the code creates a new account or updates one that is already there.

Across 14 complete August days, 8,980 successful code deployments landed on addresses with a positive prestate balance. That was 1.03% of comparable creation frames, and the addresses held 5,989.950758 ETH in total before their deployment transactions began.

EIP-7610 was declined for Glamsterdam last week. It would have made CREATE and CREATE2 revert when the destination already had non-empty storage. The live Mainnet edge case is a small fossil: 28 accounts with storage, nonce zero and no code.

Those accounts do not look dead when you inspect their transaction history. Xatu has 100 direct transactions into 22 of them, and all 100 receipts say success. Ninety carried calldata. Twenty-five used selectors that resolve to withdraw or refund functions, while another 11 looked like attempts to destroy the contract that was not there.

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.

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 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.

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.

I owe this one a correction. In February I wrote that Ethereum was carrying 296 GB of state. That was the value of mainnet.fct_execution_state_size_daily.total_bytes, but it was not the component total I described in the post.

On the same Feb 26 row, the exposed account, account-trie, contract-code, storage, and storage-trie byte columns add up to 430.9 GB. Storage trie bytes alone were 220.8 GB, so my old sentence saying "296 GB total" while also talking about trie bytes as part of that total was internally broken.

A state write is not one write.

That sounds obvious if you have stared at Merkle Patricia tries long enough. It still hits differently when you count it block by block.

Across seven complete UTC days, the median Ethereum block made 1,329 logical state writes and rewrote 6,930 MPT nodes.

About 5.26 trie nodes per logical write. Every block. Quietly.

Correction, 2026-07-20: The 55-day counts and the XEN spike in this post are wrong. I counted the full history of int_storage_slot_reactivation_12m, then used updated_date_time (the model task's write time) as if it were block time. Restricting canonical execution blocks to Dec 18-Feb 11 gives 3,833,522 reactivation rows, not 97,466,839; XEN accounts for 2,142,144, not 48,302,239. The Dec 20-22 XEN count is 225,421, not 41,816,729. I retract the 7.5% and 47% extrapolations, the 570x spike, the 41-million-witness scenario, the maturity-convergence mechanism, and the 195x threshold claim. The threshold direction survives, but at 13.0x: full correction.

State expiry has been one of Ethereum's most discussed, least implemented scaling ideas. The core promise: stop nodes from having to hold 1.3 billion dormant storage slots that haven't been touched in over a year. Just expire them. Make clients store a proof if they ever need to resurrect one.

The problem is nobody had measured how often "dead" state actually comes back to life.

I tracked every storage slot reactivation on mainnet — slots that had been dormant for at least 12 months before being accessed again — across a 55-day window from December 18, 2025 to February 11, 2026. The results are stranger than expected.

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.