This EIP introduces a mechanism to dynamically price SSTORE operations based on the storage size of a contract. A new optional storage_count field is added to the account RLP, which tracks the number of storage slots it owns. The gas cost for SSTORE will be augmented by a factor that grows exponentially with this storage_count field, but only after it crosses a predefined activation threshold. This change aims to align the cost of state growth with the long-term burden it places on the network, thereby disincentivizing state bloat.
Ethereum's state size is a growing concern, as it directly impacts node synchronization times, hardware requirements, and overall network health. The current gas model for storage operations does not fully account for the long-term cost of maintaining state indefinitely. As a result, it remains economically viable to deploy contracts with large storage footprints (“state bloat”), which can be exploited for low-cost data anchoring or spam. This imposes a negative externality on all network participants, who must store and process this data indefinitely.
In practice, the computational and I/O costs of creating and updating storage slots scale with the number of storage slots a contract owns. However, the current gas pricing model does not meaningfully increase with storage size. This discrepancy underprices workloads for contracts with very large state and slows down state root computation.
This proposal aims to address the state growth problem by creating a direct economic link between the size of a contract's storage and the cost to expand it further. By progressively increasing the price of SSTORE operations in proportion to how much storage a contract already owns, storage write costs become more aligned with the actual work clients perform. Contracts that contribute disproportionately to state growth will face rising costs for additional writes, while small and medium-sized contracts remain unaffected. This mechanism creates a market-based incentive for developers to use onchain storage efficiently, helping mitigate unsustainable state growth over time.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
| Name | Value | Description |
|---|---|---|
FORK_TIMESTAMP | TBD | Fork activation timestamp |
LIN_FACTOR | TBD | Linear gas cost factor |
ACTIVATION_THRESHOLD | TBD | Activation threshold, chosen to be at ~8GB of data. |
TRANSITION_REGISTRY_ADDRESS | TBD | The address of system contract that holds the information of account transition |
TRANSITION_SLOTS_PER_BLOCK | TBD | The number of storage slots to iterate per block during the transition process |
TRANSITION_MAX_ACCOUNTS | TBD | The number of accounts to iterate per block during the transition process |
Account RLP descriptors receive an optional storage_count field, corresponding to the current number of storage slots it contains.
At FORK_TIMESTAMP, the transition is activated.
The transition process involves reading all accounts and count the number of storage slots for accounts with non-empty storage root hashes, which in turn populates the storage_count field in the account.
The progress of the transition is stored at system contract at TRANSITION_REGISTRY_ADDRESS.
Storage layout at TRANSITION_REGISTRY_ADDRESS:
0x00: cursor_account_hash (32-byte account hash)0x01: cursor_slot_hash (32-byte slot hash)0x02: cursor_accum (uint256 count of non-zero slots seen for the current account)At the end of each block, the client performs up to TRANSITION_SLOTS_PER_BLOCK storage slot iterations, possibly spanning one account or multiple accounts:
Select account
If cursor_account_hash == 0x00…00, set it to the smallest account hash that is present in the state trie. Otherwise, continue with cursor_account_hash.
Iterate storage slots
If the current account at cursor_account_hash has a non-empty storageRootHash, visit storage slots of this account in ascending lexicographic order of slot hash, starting strictly after cursor_slot_hash (or from the beginning if cursor_slot_hash == 0x00…00).
cursor_accum slot for every slot hash seenTRANSITION_SLOTS_PER_BLOCK slots have been processed, orFinalize account (if exhausted)
If all storage slots for cursor_account_hash have been visited, set storage_count(cursor_account) to cursor_accum in the account object.
If TRANSITION_MAX_ACCOUNTS accounts are iterated, then stop iterating.
cursor_account_hash = next account hash that is present in the state triecursor_slot_hash = 0x00…00, cursor_accum = 0Persist
If either TRANSITION_SLOTS_PER_BLOCK or TRANSITION_MAX_ACCOUNTS is reached, write cursor_account_hash, cursor_slot_hash, and cursor_accum to the registry in the post-state of the block.
Completion
The transition is complete when there is no further account present in the trie, with an account hash that is lexicographically greater than the current cursor_account_hash.
The account hashes and slot hashes are iterated in ascending lexicographical order.
Transition reference: EIP-7612
Chain reorganizations require no special handling beyond normal block re-execution. The mechanism is reorg-safe.
storage_count updates and the transition cursors (cursor_account_hash, cursor_slot_hash, cursor_accum) are ordinary state writes committed in the post-state of each block at TRANSITION_REGISTRY_ADDRESS. On a reorg, these values revert to those of the new canonical ancestor and are re-derived by re-executing blocks.
After executing all transactions in a block, clients MUST update storage_count for affected accounts as follows:
old := storage_count(A) in the block-prestate (treat as 0 if absent).new be the true count of non-zero slots for A in the post-block state.storage_count(A) := new.To compute new efficiently without scanning all storage every block, clients MUST apply net deltas derived from slots whose values changed relative to the block-prestate:
For each storage slot k of account A that was written at least once in the block:
During a transition, the transition is advanced first before applying the storage deltas, but after executing all transactions, so the gas costs of a contract that is sweeped by the iterator in this block are only applied for the next block. Update semantics when a transition is occurring:
cursor_account_hash > acc_hash ), all storage deltas are applied.acc_hash > cursor_account_hash), none of the storage deltas are applied.cursor_account_hash == acc_hash), storage deltas are applied only to the slots that have already been accounted for (i.e. cursor_slot_hash > slot_hash).For each contract account A, define S_pre(A) as the value of storage_count(A) in the parent state of the block being executed (pre-state).
For all SSTOREs in the block, implementations MUST use S_pre(A) when computing the gas cost for SSTORE. This value MUST NOT change within the block, regardless of any writes to A during the block.
If storage_count(A) is absent at block start, clients MUST treat S_pre(A) = 0.
Rationale: holding
S_pre(A)constant within the block keeps gas estimation stable and independent of transaction ordering.
The gas cost of an SSTORE is computed as such:
storage_count is RLP-encoded as a minimal-length big-endian byte string (no leading zeros). The per-account overhead is therefore small and not a fixed 32 byte number. The field is present only for accounts with a non-empty storage root hash. If storage_count == 0, the field may be omitted.
Per-account overhead
L = bytes_required(storage_count):
L = 0 for 0 (field may be omitted entirely)L = 1 for 1 … 255L = 2 for 256 … 65,535L = 3 for 65,536 … 16,777,215L = 4 for 16,777,216 … 4,294,967,295 (≈ 4.29B)L ≤ 55)For context, at block ~23,000,000 the largest contract has about 80M storage slots. Even at that scale (L = 4), the per-account addition remains ≤ 6 bytes.
If we pessimistically assume 23,000,000 contract accounts each carry storage_count and each incurs the worst-case 6 bytes, the upper bound is:
23,000,000 × 6 = 138,000,000 bytes ≈ 138 MBThis is a conservative upper bound. In practice, most contracts have far fewer slots (L ≤ 1–3), so a typical addition is 2–4 bytes per contract. Therefore, the net impact on state size is negligible.
The intent is to create friction when growing the state size of a contract, thus limiting the number of such contracts. Going over the limit, some contract developers might want to use another contract to start fresh, which comes at the cost of paying for contract creation, and for any call into the previous instance of the contract.
ACTIVATION_THRESHOLD is chosen to not penalize the contracts that are large, but do provide useful value. The idea is to disincentivize spam contracts that grow larger than useful contracts, the latter being legitimately big due to the value they bring to their users and the wider ecosystem. This means that this constant could be increased as the state grows.
TRANSITION_MAX_ACCOUNTS bounds how many accounts may be finalized (i.e. have their storage_count written) per block during the transition. This prevents excessive write operations per block, reducing write amplification and avoiding large database compactions and associated performance degradation. It complements TRANSITION_SLOTS_PER_BLOCK, which limits how many storage slots are scanned per block in line with the minimal hardware recommendations. In short, TRANSITION_SLOTS_PER_BLOCK bounds read operations, while TRANSITION_MAX_ACCOUNTS bounds write operations.
The largest contract observed (XEN) sits around depth 9, meaning its relevant storage keys share a 9-nibble (~4.5 bytes) prefix along their MPT paths. Because the storage key into the trie is keccak256(slot_key), an attacker can easily calculate the inputs offchain to find hashes and populate all contracts such that they pay the same cost as XEN.
If counting began only at FORK_TIMESTAMP, every existing contract would start with an implicit storage_count = 0 and accrue counts only from new writes. While spammy contracts would quickly accumulate writes and thus incur penalties, this would still misprice the workloads we intend to regulate: large pre-fork contracts would continue paying unscaled base costs until they rewrote a substantial portion of their historical slots. During that period, gas pricing would understate their actual storage footprint.
A deterministic, in-protocol transition avoids this. By iterating existing storage under consensus rules and progressively populating each account’s storage_count in the state, we ensure that storage-size-based pricing reflects reality for all contracts—regardless of whether they write again after the fork. Persisting cursor progress under the state root also makes the process reorg-safe and client-agnostic.
Alternative (pre-fork background counting by clients)
FORK_TIMESTAMP. At activation, they only need to write the final counts into the state for a fixed number of accounts.In the current two-layer MPT, a write to contract storage accesses an account path and then a storage path, and the cost a client pays in trie updates and database reads/writes correlates with how deep the storage trie becomes over time.
Under a unified tree, the per-write computational and I/O cost of SSTORE no longer tracks an account’s total number of storage slots. The path length is set by the global tree’s branching factor and height, and by the overall distribution of state keys, not by a single account’s footprint. As a result, progressive pricing based on an account’s slot count can become misaligned with the actual work once a unified tree ships.
Because EIP-2926 also requires an account transition to chunkify the bytecode and additional fields, scheduling both EIPs in the same fork enables a single, combined transition. This removes duplicated work, reduces client complexity and the number of tree transitions in the future.
No backward compatibility issues found. Making the storage_count field optional ensures that the default count is 0, which means that contract will not be affected by the gas increase before they have been reached by the iterator sweep.
This is a backwards incompatible gas repricing that requires a scheduled network upgrade.
Node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically, RPC methods such as eth_estimateGas MUST incorporate the updated formula for gas calculation when encountering an SSTORE.
Users and wallets can maintain their usual workflows without modification, as RPC updates will handle these changes.
TODO
TODO
Needs discussion.
Copyright and related rights waived via CC0.