---
eip: 8037
title: State Creation Gas Cost Increase
description: Harmonization, increase and separate metering of state creation gas costs to mitigate state growth and unblock scaling
author: Maria Silva (@misilva73), Carlos Perez (@CPerezz), Jochem Brouwer (@jochem-brouwer), Ansgar Dietrichs (@adietrichs), Łukasz Rozmej (@LukaszRozmej), Anders Elowsson (@anderselowsson), Francesco D'Amato (@fradamt)
discussions-to: https://ethereum-magicians.org/t/eip-8037-state-creation-gas-cost-increase/25694
status: Draft
type: Standards Track
category: Core
created: 2025-10-01
requires: 2780, 6780, 7623, 7702, 7825, 7904, 7928, 7976, 7981, 8038
---

## Abstract

This proposal increases the cost of state creation operations, thus avoiding excessive state growth under increased block gas limits. It introduces a new variable, `CPSB` (cost per state byte), and sets this unit of gas costs per new state byte by targeting an average state growth of 120 GiB per year at a reference block gas limit of 150M gas units. It also introduces an independent metering for state creation costs, thus allowing for increased throughput and for larger contract deployments without being limited by the single transaction gas limit.

## Motivation

State creation does not have a harmonized cost, with different methods incurring varied costs for creating the same size of new state. For instance, while contract deployment only costs ~200 gas units per new byte created, new storage slots cost ~313 gas units per new byte created. Also, deploying duplicated bytecode costs the same as deploying new bytecode, even though clients don't store duplicated code in the database. This proposal establishes a standard to harmonize all state creation operations.

Additionally, state growth will become a bottleneck for scaling under higher block limits. As of January 2026, the current database size in a Geth node dedicated to state is ~390 GiB. After the increase in gas limit from 30M to 60M gas units, the average size of new state created each day more than tripled, from ~105 MiB to ~326 MiB. This results in an annual growth of ~116 GiB.

![new_state_added](../assets/eip-8037/new_state_added.png)

The state-growth response we observe is not linear in the gas limit increase: a 2x bump (30M → 60M) produced a roughly 3x jump in daily new state, suggesting a one-off shift in user behavior rather than a steady-state ratio. Treating the post-bump rate as the new baseline and extrapolating proportionally to the new gas limit, at a 200M gas limit, the state would grow at a rate of ~387 GiB per year. Starting from 390 GiB, this rate would breach the 650 GiB threshold (at which point nodes begin experiencing performance degradation) in less than a year.

## Specification

### New parameters

| **Parameter** | **Value** |
|:---:|:---:|
| `CPSB` | 1530 |
| `STATE_BYTES_PER_STORAGE_SET` | 64 |
| `STATE_BYTES_PER_NEW_ACCOUNT` | 120 |
| `STATE_BYTES_PER_AUTH_BASE` | 23 |
| `SYSTEM_MAX_SSTORES_PER_CALL` | 16 |

### Parameter changes

Upon activation of this EIP, the following parameters of the gas model are updated. The "New State Gas" column shows the state gas cost (charged to the state-gas dimension), while the "New Regular Gas" column shows additional regular gas costs that accompany the state gas charge.

| **Parameter** | **Current** | **New State Gas** | **New Regular Gas** | **Operations affected** |
|---|---|---|---|---|
| `GAS_CREATE` | 32,000 | `STATE_BYTES_PER_NEW_ACCOUNT x CPSB` | `CREATE_ACCESS` | `CREATE`, `CREATE2` |
| `GAS_CODE_DEPOSIT` | 200/byte | `CPSB` per byte | `6 × ceil(len/32)` (hash cost) | `CREATE`, `CREATE2` |
| `GAS_NEW_ACCOUNT` | 25,000 | `STATE_BYTES_PER_NEW_ACCOUNT x CPSB` | 0 | `CALL`, `CALLCODE`, `SELFDESTRUCT` |
| `GAS_STORAGE_SET` | 20,000 | `STATE_BYTES_PER_STORAGE_SET x CPSB` | 0 | `SSTORE` |
| `PER_EMPTY_ACCOUNT_COST` | 25,000 | `STATE_BYTES_PER_NEW_ACCOUNT x CPSB` | `ACCOUNT_WRITE` | EOA delegation |
| `PER_AUTH_BASE_COST` | 12,500 | `STATE_BYTES_PER_AUTH_BASE x CPSB` | `REGULAR_PER_AUTH_BASE_COST` | EOA delegation |

The `REGULAR_PER_AUTH_BASE_COST` is defined as the sum of:

- Calldata cost: 1,616 (101 bytes × 16)
- Recovering authority address (ecRecover): `PRECOMPILE_ECRECOVER` (is updated by [EIP-7904](./eip-7904.md))
- Reading nonce and code of authority (cold access): `COLD_ACCOUNT_ACCESS` (is updated by [EIP-8038](./eip-8038.md))
- Storing values in an already warm account: 2 x `WARM_ACCESS`

`COLD_ACCOUNT_ACCESS`, `ACCOUNT_WRITE` and `CREATE_ACCESS` are defined and updated in [EIP-8038](./eip-8038.md). The values are not yet final.

### Multidimensional metering for state creation costs

Besides the parameter changes, this proposal introduces an independent metering for state creation costs. Two gas dimensions are introduced, regular-gas and state-gas. For state creation operations, the "new state costs" are charged to state-gas, while the "new regular costs" are charged to regular-gas. The costs of all other operations are charged to regular-gas.

At transaction level, the user pays for both regular-gas and state-gas. The total gas cost of a transaction is the sum of both dimensions. In addition, the transaction gas limit set in [EIP-7825](./eip-7825.md) only applies to regular-gas, while state-gas is only capped by `tx.gas`.

At the block level, only the gas used in the bottleneck resource is considered when checking if the block is full and when updating the base fee for the next block. This gives a new meaning to the block's gas limit and the block's gas target: each now bounds the bottleneck resource (the dimension with the highest cumulative gas used) rather than a single combined gas counter.

#### Transaction validation

Before transaction execution, inclusion of a transaction in a block requires that:

1. The transaction's **intrinsic costs are not higher than [EIP-7825](./eip-7825.md)'s transaction cap**. Concretely, `max(intrinsic_regular_gas, calldata_floor_gas_cost) <= TX_MAX_GAS_LIMIT`, where `intrinsic_regular_gas` includes all the intrinsic costs not associated with state created (i.e., base transaction cost, calldata, access lists, authorization base costs).
2. For each gas dimension, the **cumulative gas used of all previous transactions added to the transaction's contribution does not exceed the block gas limit**. Concretely, `min(TX_MAX_GAS_LIMIT, tx.gas) <= regular_gas_available` and `tx.gas <= state_gas_available`, where `regular_gas_available = block_env.block_gas_limit - block_output.block_regular_gas_used` and `state_gas_available = block_env.block_gas_limit - block_output.block_state_gas_used`.

This check is performed before transaction inclusion in a block.

`intrinsic_regular_gas` is the sum of:

- Transaction base cost
- Calldata cost
- Access list gas cost
- Authorizations regular gas cost (`ACCOUNT_WRITE` + `REGULAR_PER_AUTH_BASE_COST` per authorization)
- Create transaction regular gas cost (`CREATE_ACCESS` if it is a create tx)

`intrinsic_state_gas` is the sum of:

- Authorizations state gas cost ((`STATE_BYTES_PER_NEW_ACCOUNT` + `STATE_BYTES_PER_AUTH_BASE`) x `CPSB` per authorization)
- Create transaction state gas (`STATE_BYTES_PER_NEW_ACCOUNT` x `CPSB` if it is a create tx)

#### Transaction-level gas accounting (reservoir model)

Since transactions have a single gas limit parameter (`tx.gas`), gas accounting is enforced through a **reservoir model**, in which `gas_left` and `state_gas_reservoir` are initialized as follows:

```python
intrinsic_gas = intrinsic_regular_gas + intrinsic_state_gas
execution_gas = tx.gas - intrinsic_gas
regular_gas_budget = TX_MAX_GAS_LIMIT - intrinsic_regular_gas
gas_left = min(regular_gas_budget, execution_gas)
state_gas_reservoir = execution_gas - gas_left
```

This means that the `state_gas_reservoir` holds gas that exceeds [EIP-7825](./eip-7825.md)'s budget. Additionally, two new counters are introduced:

- `execution_regular_gas_used` encodes the total regular-gas used by the transaction, and it is initialized as `execution_regular_gas_used = 0`.
- `execution_state_gas_used` encodes the total state-gas used by the transaction, and it is initialized as `execution_state_gas_used = 0`.

The gas counters operate as follows:

- Regular-gas charges deduct from `gas_left` only and increment `execution_regular_gas_used`.
- State-gas charges deduct from `state_gas_reservoir` first. When the reservoir is exhausted, state-gas charges deduct from `gas_left`. State-gas charges increment `execution_state_gas_used`.
- If a state creation is undone during execution, the corresponding amount of state-gas is refilled back to the reservoir. State-gas refills decrement `execution_state_gas_used`.
- The `GAS` opcode returns `gas_left` only (excluding the reservoir).
- State-gas is metered at the end of all state-mutating opcodes, call-frame boundaries (in case of exceptional halts and reverts) and at the end of the transaction.

##### Gas accounting for SSTORE (opcode-level)

| Original value | Current value | New value | Description | State-gas charges/refills |
|---|---|---|---|---|
| 0 | x | 0 | Cleared slot, zero at transaction start | `STATE_BYTES_PER_STORAGE_SET × CPSB` refilled |
| 0 | 0 | x | New slot | `STATE_BYTES_PER_STORAGE_SET × CPSB` charged |
| x | x | 0 | Cleared slot, non-zero at transaction start | no state-gas adjustments |
| x | 0 | x | Cleared slot restored to its original non-zero value | no state-gas adjustments |
| x or 0 | y | z | All other writes to an existing slot | no state-gas adjustments |

State-gas accounting for `SSTORE` is performed at the end of the opcode execution.

##### Gas accounting for new accounts

| Operation | State-gas charges/refills |
|---|---|
| `CALL*` with value to non-existent account | `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` charged |
| `CREATE`/`CREATE2` with bytecode size of `L` | `(STATE_BYTES_PER_NEW_ACCOUNT + L) × CPSB` charged |
| `SELFDESTRUCT` where balance transfer creates a new account | `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` charged |

State-gas accounting for `CALL*` and `CREATE`/`CREATE2` operations is performed right before the respective call frame. If the respective call frame reverts or halts exceptionally, the charged state-gas is refilled back to the `state_gas_reservoir` and `execution_state_gas_used` decreases by the same amount.

The same applies to top-level contract-creation transactions. If the transaction reverts or halts, the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` portion of `intrinsic_state_gas` is refilled back to `state_gas_reservoir` and `execution_state_gas_used` decreases by the same amount.

Charges for account creation with `SELFDESTRUCT` are charged at the point where it executes.

##### Gas refills for `SELFDESTRUCT`

`SELFDESTRUCT` for accounts created in the same transaction does not produce increases in state size as the account, its data and its storage is not included in the state trie. However, this operation does not produce any state-gas refills and there are no changes to `execution_state_gas_used`.

For an account that existed before the transaction, `SELFDESTRUCT` only transfers its balance and the account is not removed. Thus, no state-gas refill applies and no changes to `execution_state_gas_used`. This is consistent with the behavior of [EIP-6780](./eip-6780.md).

##### Gas accounting for halts and reverts

After a revert, all state changes performed on the child frame are rolled back and all state-gas charged on the child frame is refunded to the parent frame's `state_gas_reservoir` and the remaining `gas_left` of the child frame is given back to the parent frame (added to `gas_left`), consistent with existing EVM semantics. `execution_state_gas_used` is decreased consistently, while `execution_regular_gas_used` is updated according to the regular gas consumed by the child frame before the revert.

After an exceptional halt, `state_gas_reservoir` is reset back to its value at the start of the child frame (i.e., all state-gas charges on the child frame are refunded to the parent frame) and the `gas_left` initially given to the child is consumed (set to zero), consistent with existing EVM semantics. `execution_state_gas_used` and `execution_regular_gas_used` are updated accordingly.

The same rules apply when the top-level call frame reverts or halts. Here, `state_gas_reservoir`, `execution_state_gas_used`, and `execution_regular_gas_used` are updated as if the frame were a child of the transaction boundary. In particular, for address collisions in contract-creation transactions, `gas_left` is consumed in full, `execution_regular_gas_used` is incremented by the initial `gas_left`, and the new-account portion of `intrinsic_state_gas` is refunded per the rule above.

##### Gas accounting for [EIP-7702](./eip-7702.md) authorizations

While computing the intrinsic gas cost, [EIP-7702](./eip-7702.md) authorizations are charged the worst-case cost for each delegation. Then, during authorization processing, the following gas adjustments are made for each processed authorization:

- If the `authority`'s account leaf already exists (i.e., non-zero nonce, non-zero balance, or non-empty code), the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` portion is refilled directly to `state_gas_reservoir` and the `ACCOUNT_WRITE` portion is refunded to the refund counter.
- If the `authority`'s `codeHash` is not `emptyHash` (i.e., a prior authorization indicator already occupies the 23 bytes) or `authorization.address` is `ZERO` (the authorization is clearing the delegation), the `STATE_BYTES_PER_AUTH_BASE × CPSB` portion is also refilled directly to `state_gas_reservoir`.

`execution_state_gas_used` decreases by the corresponding amount of state-gas refills.

Because `execution_state_gas_used` is initialized to `0`, this refill may bring it below zero before any execution-time charges. Implementations may equivalently track the refill separately and subtract it from `tx_state_gas` when accumulating `block_state_gas_used`.

#### Pre-state and post-state gas validation

[EIP-7928](./eip-7928.md) defines two-phase gas validation for state-accessing opcodes: pre-state costs (determinable without state access) and post-state costs (requiring state access). Under this EIP, the regular-gas portion of these opcodes follows the [EIP-7928](./eip-7928.md) rules unchanged and is charged at opcode time against `gas_left`. The state-gas portion is also charged at the opcode level; it is computed and deducted at the end of the opcode execution, drawing first from `state_gas_reservoir` and then from `gas_left`.

For `SSTORE`, the `GAS_CALL_STIPEND` pre-state check ([EIP-7928](./eip-7928.md)) applies to `gas_left` only, excluding the `state_gas_reservoir`.

#### Transaction gas used

At the end of transaction execution, the gas used before and after refunds is defined as:

```python
tx_gas_used_before_refund = tx.gas - tx_output.gas_left - tx_output.state_gas_reservoir
tx_gas_refund = min(tx_gas_used_before_refund // 5, tx_output.refund_counter)
tx_gas_used_after_refund = tx_gas_used_before_refund - tx_gas_refund
```

The refund cap remains at 20% of gas used.

#### Block-level gas accounting

At block level, instead of tracking a single `gas_used` counter, we keep track of two counters, one for `state-gas` and one for `regular-gas`:

```python
tx_regular_gas = intrinsic_regular_gas + tx_output.execution_regular_gas_used
tx_state_gas = intrinsic_state_gas + tx_output.execution_state_gas_used

tx_gas_used = max(tx_gas_used_after_refund, calldata_floor_gas_cost)
block_output.block_regular_gas_used += max(tx_regular_gas, calldata_floor_gas_cost)
block_output.block_state_gas_used += tx_state_gas
```

Note: `tx_gas_used` applies the [EIP-7623](./eip-7623.md) calldata floor after refunds, so the floor can effectively negate part of a refund when `calldata_floor_gas_cost > tx_gas_used_after_refund`. The receipt `cumulative_gas_used` uses this post-floor value.

The block header `gas_used` field is set to:

```python
gas_used = max(block_output.block_regular_gas_used, block_output.block_state_gas_used)
```

The block validity condition uses this value:

```python
assert gas_used <= block.gas_limit, 'invalid block: too much gas used'
```

The base fee update rule is also modified accordingly:

```python
gas_used_delta = parent.gas_used - parent.gas_target
```

#### Receipt semantics

Receipt `cumulative_gas_used` tracks the cumulative sum of `tx_gas_used` (post-refund, post-floor) across transactions, instead of the block's `gas_used`. This means `receipt[i].cumulative_gas_used - receipt[i-1].cumulative_gas_used` equals the gas paid by transaction `i`.

### System contracts and system transactions

The gas limit of system contracts (e.g., [EIP-2935](./eip-2935.md), [EIP-4788](./eip-4788.md), [EIP-7002](./eip-7002.md), [EIP-7251](./eip-7251.md)) that are invoked at the start of every block via a system call is updated from 30M to:

```python
SYSTEM_CALL_GAS_LIMIT = 30_000_000 + STATE_BYTES_PER_STORAGE_SET × CPSB × SYSTEM_MAX_SSTORES_PER_CALL
```

This ensures preservation of the existing execution margin for system contracts under higher state creation costs.

Here, `SYSTEM_MAX_SSTORES_PER_CALL = 16` is the upper bound on the number of new storage slots a single system call is expected to write. This value matches `MAX_WITHDRAWAL_REQUESTS_PER_BLOCK` ([EIP-7002](./eip-7002.md)), the largest per-block bound across the existing system contracts.

The additional `STATE_BYTES_PER_STORAGE_SET × CPSB × SYSTEM_MAX_SSTORES_PER_CALL` is placed in `state_gas_reservoir` while the rest of the system call's execution gas is placed in `gas_left`. System calls remain not subject to the [EIP-7825](./eip-7825.md) `TX_MAX_GAS_LIMIT` cap, do not count against the block gas limit, and do not contribute to either `block_regular_gas_used` or `block_state_gas_used`.

## Rationale

### Deriving the cost per state byte (CPSB)

`CPSB` is a fixed parameter derived from a reference block gas limit. The derivation pins the cost so that, at the reference block gas limit and under expected average utilization, total state growth stays at the target rate. If a future block gas limit increase materially changes the expected state growth rate, `CPSB` can be re-derived in a subsequent EIP.

#### Inputs

- **Target state growth**: 120 GiB per year, i.e., `120 × 2^30 = 128,849,018,880` bytes.
- **Reference block gas limit**: 150M gas units.
- **Slot time**: 12 seconds, giving `86400 / 12 = 7,200` blocks per day and `7,200 × 365 = 2,628,000` blocks per year.
- **Average state-gas utilization**: 50% of the block gas limit. Under multidimensional metering, the base fee equilibrates around the target, which is half of the gas limit. On average, half of each block's gas budget can therefore be consumed by state-gas charges before the base fee starts pushing back.

#### Derivation

The total state gas available for state creation in a year is:

```text
total_state_gas_per_year = (gas_limit / 2) × blocks_per_year
                         = (150,000,000 / 2) × 2,628,000
                         = 75,000,000 × 2,628,000
                         = 1.971 × 10^14 gas
```

Dividing by the target byte count gives the cost per state byte:

```text
CPSB = total_state_gas_per_year / target_state_growth
     = 1.971 × 10^14 / 128,849,018,880
     ≈ 1530 gas/byte
```

#### Why target 150M block limit?

The reference block gas limit of 150M is chosen as a middle ground between the current 60M and the expected future 300M. This allows us to set a `CPSB` that is not too high (which would cause a large immediate increase in state creation costs) nor too low (which would require a more aggressive increase in a future EIP when the block limit increases further).

With this target, we expect state growth will slow down significantly compared to the current trajectory and then increase again as we slowly increase the block gas limit.

#### Why target 120 GiB per year?

By targeting a state growth of 120 GiB per year with a 150M block limit, we achieve the following worst-case growth rate at different block limits:

| Block limit | Worst-case growth rate |
| --- | --- |
| 100M | 80 GiB/year |
| 150M | 120 GiB/year |
| 200M | 160 GiB/year |
| 250M | 200 GiB/year |
| 300M | 240 GiB/year |

These rates are computed assuming blocks are fully utilized with state creation operations, which is a worst-case scenario. Assuming a smooth increase in block limit from 100M to 300M over the next year, we would expect a worst-case average growth rate of around 160 GiB per year, which is a significant improvement over the current trajectory.

### Harmonization across state creation

With the current pricing, the gas cost of creating 1 byte of state varies depending on the method used. The following table shows the various methods and their gas cost per byte. The calculation ignores the transaction intrinsic cost (21k gas units) and the costs of additional opcodes and scaffolding needed to execute such a transaction.

| Method                                                      | What is written                                | Intrinsic gas                                                                                 | Bytes → state | Gas / byte |
| ----------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------- | ---------- |
| Deploy 24kB contract ([EIP-170](./eip-170.md) limit)        | Runtime code + account trie node               | 32,000 CREATE + 200 × 24,576 code deposit = 4,947,200 gas                | 24,696 B      | ~200 gas   |
| Fund fresh EOA with 1 wei                                   | Updated account leaf                           | 25,000 new account                                                                            | ~120 B        | ~208 gas   |
| Add delegate flag to funded EOA ([EIP-7702](./eip-7702.md)) | 23 B (0xef0100‖address) + updated account leaf | 25,000 PER_EMPTY_ACCOUNT + 12,500 PER_AUTH_BASE + 1,616 calldata - 7,823 refund = ~31,300 gas | ~143 B        | ~219 gas   |
| [EIP-7702](./eip-7702.md) authorization to empty address    | 23 B (0xef0100‖address) + updated account leaf | 25,000 PER_EMPTY_ACCOUNT + 12,500 PER_AUTH_BASE + 1,616 calldata = 39,116 gas                 | ~143 B        | ~274 gas   |
| Fill new storage slots (SSTORE 0→x)                         | Slot in storage trie                           | 20,000 gas/slot                                                                               | 64 B          | ~313 gas   |

To harmonize costs, we first set the gas cost of a single state byte, `CPSB`, as explained above. Now that we have a standardized cost per byte, we can derive the various costs parameters by multiplying the unit cost by the increase in bytes any given operation creates in the database (i.e., 64 bytes per slot, 120 bytes per account and 23 bytes per authorization).

Note that the fixed cost `GAS_CREATE` for contract deployments assumes the same cost as a new account creation.

#### Deriving byte size for new slots and accounts

The byte sizes used in this proposal correspond to the on-disk footprint of a new account or storage slot, taking into account both the leaf data and the key under which it is stored.

A new account adds 120 bytes:

| Field | Size |
| --- | --- |
| Account hash (key) | 32 bytes |
| Nonce | 8 bytes |
| Balance | 16 bytes |
| Code hash | 32 bytes |
| Storage root | 32 bytes |
| **Total** | **120 bytes** |

A new storage slot adds 64 bytes:

| Field | Size |
| --- | --- |
| Slot hash (key) | 32 bytes |
| Value | 32 bytes |
| **Total** | **64 bytes** |

For [EIP-7702](./eip-7702.md) authorizations on an already-existing account, no new account leaf is created. The only new state written is the delegation indicator stored in the authority's `code` field. As specified in [EIP-7702](./eip-7702.md), this indicator is the 3-byte magic prefix `0xef0100` concatenated with the 20-byte delegate address, for a total of 23 bytes:

| Field | Size |
| --- | --- |
| Delegation magic (`0xef0100`) | 3 bytes |
| Delegate address | 20 bytes |
| **Total** | **23 bytes** |

When the authorization targets a non-existent account, the full `STATE_BYTES_PER_NEW_ACCOUNT` is charged in addition to `STATE_BYTES_PER_AUTH_BASE`, since both a new account leaf and the delegation indicator are written.

These figures account only for the leaf payload and its keccak256 key. They do not include the additional trie overhead (intermediate nodes, encoding, etc.) incurred when the new entry is inserted. The values are therefore a lower bound on the actual state growth per operation.

### Multidimensional metering

#### EIP-7825 limit on contract size

[EIP-7825](./eip-7825.md) introduces `TX_MAX_GAS_LIMIT` (16.7M) as the maximum gas for a single transaction, in particular stipulating `tx.gas < TX_MAX_GAS_LIMIT`as a validity condition. Were we to continue enforcing this validity condition, with `CPSB = 1530`, this proposal would limit the maximum contract size that can be deployed to roughly 7.5kB. Assuming a representative constructor execution budget of 5M regular gas on top of the 21,000 base transaction cost and the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` account-creation cost, the remaining budget for code-deposit state gas yields $\frac{16,777,216 - 21,000 - 5,000,000 - 120 \times 1530}{1530} \approx 7{,}564$ bytes. This maximum size would only decrease if `CPSB` is re-derived upward in a future EIP.

To solve this issue, we only apply this gas limit to regular gas, not state gas. Doing so does not weaken the intended scaling effect of [EIP-7825](./eip-7825.md), because regular gas meters all resources that benefit from parallelization. In particular, state growth does not: growing the state always requires writing to disk, a parallelizable operation, but crucially this part of the cost of a state growth operation has to be metered in regular gas, not state gas. In other words, any operation that grows the state should consume both regular gas and state gas, and the regular gas should fully account for all costs other than the long term effect of growing the state.

However, we cannot statically enforce a regular gas consumption of `TX_MAX_GAS_LIMIT`, while still allowing a higher state gas consumption, because transactions only have a single gas limit parameter, `tx.gas`. This is solved through a **reservoir model**: at transaction start, execution gas is split into `gas_left` (capped at `TX_MAX_GAS_LIMIT - intrinsic_regular_gas`) and a `state_gas_reservoir` (the overflow). State gas charges draw from the reservoir first, then from `gas_left` when the reservoir is empty. Regular gas charges draw from `gas_left` only. Exceeding the regular gas budget behaves identically to running out of gas — no special error is needed.

#### Higher throughput

Another advantage of metering contract creation separately is that increasing the cost of state creation operation in line with the block limit will not affect the available gas for other operations. This allows for higher throughput, as explained in the original multidimensional gas metering introduced in [EIP-8011](./eip-8011.md).

## Backwards Compatibility

This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.

Wallet developers and node operators MUST update gas estimation handling to accommodate the new state creation costs and the two-dimensional metering model. Specifically:

- Wallets: Wallets using `eth_estimateGas` MUST be updated to ensure they correctly account for the updated state creation costs and report `tx.gas` covering both the regular-gas and state-gas dimensions. Failure to do so could result in underestimating gas, leading to failed transactions.
- Node Software: RPC methods such as `eth_estimateGas` MUST incorporate the new state-gas charges, the reservoir-model accounting, and the two-dimensional block accounting when computing gas estimates.

Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.

### Estimated price impacts

Users and dApp developers will experience an increase in transaction costs associated with creating a new state. The next table summarizes the state-gas portion of state creation costs for common operations under the proposed `CPSB` of 1,530. Additional regular-gas charges (e.g., `ACCOUNT_WRITE`, `STORAGE_WRITE`, hash cost) defined in [EIP-8038](./eip-8038.md) apply on top.

| Case | Current gas cost | Proposed gas cost | Gas cost increase | Proposed cost (ETH) |
|:---:|---|---|---|---|
| New account | 25,000 | 183,600 | ~7x | 0.0000147 |
| New slot | 20,000 | 97,920 | ~5x | 0.00000783 |
| 24kB contract deployment | 4,947,200 | 37,784,880 | ~8x | 0.00302 |

The "Proposed cost (ETH)" column assumes a base fee of 0.08 Gwei, which corresponds to the average base fee observed after the 60M gas increase in December 2025 and January 2026.

## Security Considerations

Increasing the cost of state creation operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.

### Mispricing with respect to ETH transfers

One potential concern is the cost of creating a new account (`STATE_BYTES_PER_NEW_ACCOUNT × CPSB` gas units, e.g., 183,600 at the proposed `CPSB`), compared to transferring ETH to a fresh account (21,000 gas units). With this mismatch, users wishing to create a new account are incentivized to first send a normal transaction (costing 21k) to this account to create it, thus avoiding the `GAS_NEW_ACCOUNT` charge.

[EIP-2780](./eip-2780.md) solves this mispricing by adding a new component to the intrinsic gas cost of transactions. If a non-create transaction has value > 0 and targets a non-existent account, the `GAS_NEW_ACCOUNT` is added to intrinsic cost.

### Added complexity in block building

Optimal block construction becomes more complex, since builders must now balance resource usage across multiple dimensions rather than a single gas metric. Sophisticated builders may gain an advantage by applying advanced optimization techniques, raising concerns about further builder centralization. However, practical heuristics (e.g., greedily filling blocks until one resource dimension saturates) remain effective for most use cases. These heuristics limit centralization pressure by keeping block construction feasible for local and less sophisticated builders.

### Interaction with [ERC-4337](./eip-4337.md) bundles

The `GAS` opcode returns `gas_left` only and cannot observe `state_gas_reservoir`. Bundling protocols that meter sub-call consumption via `gasleft()` deltas (e.g., the [ERC-4337](./eip-4337.md) `EntryPoint`) therefore cannot accurately attribute state-gas usage when it is funded by the reservoir. Because all user operations in a bundle share the transaction's reservoir, one user operation's state-gas refunds can subsidize another's state-gas charges without appearing in either's `gasleft()` delta. Bundlers and `EntryPoint` implementations MUST account for state-gas charges and refunds explicitly rather than relying on `gasleft()` differences alone.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).