EIP-8038 State access gas cost update (State-Access Gas Cost Update)

No call decision · Fees & gas · EIP status Last Call · created 2025-10-03

Raises the gas cost of instructions that read and write accounts or storage slots. As Ethereum state has grown and these operations have become slower, the costs are repriced by splitting them into three components: access, write and creation.

Why it is needed

Gas converts the time and resources a node spends processing a transaction into a price. The price of reading and writing state on disk, such as account balances and contract storage, had stayed the same since EIP-2929 raised it in the Berlin fork in March 2021. Since then Ethereum state has grown considerably, and reading and writing it has become correspondingly slower. With the price unchanged but the real time higher, state access has become too cheap compared with other opcodes. In addition, EXTCODESIZE and EXTCODECOPY go through the database twice, reading the account information once and then reading the code size or bytecode once more, yet they charged the same as BALANCE or EXTCODEHASH, which read only once. This proposal readjusts these prices based on execution times actually measured per client, and separates the write cost, which had been mixed into composite constants, into named constants.

What changes

Today

After EIP-8038

Who is affected

In depth

The three components of the cost: access, write, state creation

The gas cost of an operation that touches state is seen as the sum of up to three independent components. The first is Access, the cost of reading an account or storage slot from the database. COLD_ACCOUNT_ACCESS, COLD_STORAGE_ACCESS and WARM_ACCESS belong here, and they are renamed EIP-2929 parameters. This EIP raises only COLD_ACCOUNT_ACCESS and leaves the other two and the cold and warm determination rules unchanged. The second is Write, the cost of writing a leaf when a value changes. Storage slots pay STORAGE_WRITE, and the nonce, balance and code hash of an account pay ACCOUNT_WRITE, and both are constants newly created by this EIP. In the existing scheme, this share was dissolved inside composite constants such as GAS_STORAGE_UPDATE, CALL_VALUE and GAS_CREATE. STORAGE_WRITE is netted per transaction. The SSTORE that moves a slot away from its value at the start of the transaction pays it, and the SSTORE that later reverts it is refunded. ACCOUNT_WRITE is paid per operation. Making a value-bearing CALL to the same recipient twice pays it twice. The rule of paying only once per authority when processing EIP-7702 authorizations exists only in EIP-2780. The third is State creation, which is GAS_STORAGE_SET for a new slot and GAS_NEW_ACCOUNT for a new account. This EIP does not change these values, and EIP-8037 reprices them in the state gas dimension.

Changed parameters and conversion of existing values

The values change as follows. COLD_ACCOUNT_ACCESS (formerly COLD_ACCOUNT_ACCESS_COST) goes from 2,600 to 3,000, +15%. COLD_STORAGE_ACCESS (formerly COLD_SLOAD_COST) stays at 2,100. WARM_ACCESS (formerly WARM_STORAGE_READ_COST) stays at 100. ACCOUNT_WRITE goes from the equivalent of 6,700 to 9,000, +34%. STORAGE_WRITE goes from the equivalent of 2,800 to 10,000, +257%. CREATE_ACCESS goes from the equivalent of 7,000 to 12,000, +71%. STORAGE_CLEAR_REFUND (formerly SSTORE_CLEARS_SCHEDULE) goes from 4,800 to 11,616, +142%. ACCESS_LIST_STORAGE_KEY_COST goes from 1,900 to 2,000, +5%. ACCESS_LIST_ADDRESS_COST goes from 2,400 to 2,900, +21%. The current values of the three new constants are approximations extracted from the existing composite constants. 6,700 is CALL_VALUE of 9,000 minus CALL_STIPEND of 2,300, 2,800 is GAS_STORAGE_UPDATE of 5,000 minus GAS_COLD_SLOAD of 2,100 and GAS_WARM_ACCESS of 100, and 7,000 is GAS_CREATE of 32,000 minus GAS_NEW_ACCOUNT of 25,000. The existing scheme does not divide cleanly into these components. A warm SSTORE of 2,900 matches 100 + 2,800, but a cold SSTORE of 5,000 is 100 more than the sum of the components. Contract creation transactions and CREATE and CREATE2 pay CREATE_ACCESS only once and do not separately pay COLD_ACCOUNT_ACCESS or ACCOUNT_WRITE. Setting an EOA delegation is charged only within EXECUTION_PER_AUTH_BASE_COST of EIP-8037, and because resolving a delegation reads the target code during execution, it pays the ordinary cold and warm access costs.

SSTORE pricing formula and refund rules

As in EIP-2200, the original value is the slot's value at the start of the transaction, and the current value is the value just before the SSTORE. The cost is the sum of three components. The access component is COLD_STORAGE_ACCESS if the slot is cold and WARM_ACCESS if it is warm. The write component STORAGE_WRITE is charged only when the new value differs from the current value and the current value equals the original value, that is, only when the slot is first moved away from its value at the start of the transaction. The state creation component GAS_STORAGE_SET is charged as state gas under EIP-8037 when the original and current values are 0 and the new value is nonzero. Refund rules are evaluated on every SSTORE. First, if the original and current values are nonzero and the new value is 0, STORAGE_CLEAR_REFUND is added. Second, if the original value is nonzero, the current value is 0 and the new value is nonzero, STORAGE_CLEAR_REFUND is subtracted. This reverses the first rule so that clearing and then refilling a slot in the same transaction does not yield a gain. Third, if the new value equals the original value and differs from the current value, STORAGE_WRITE is refunded. Without this reversal, a round trip from x to 0 and back to x would leave a net refund even though the slot is unchanged. Across the whole transaction, a slot that ends with a changed value pays the write and creation components exactly once, and a slot that ends at its original value pays only the access cost. Refunds accumulate in the transaction refund counter and are applied only up to 20% of total gas used. The refill rules for state gas are in EIP-8037.

Rules per account access operation

In CALL and CALLCODE, CALL_VALUE is redefined as ACCOUNT_WRITE + CALL_STIPEND, and the CALL_STIPEND of 2,300 stays the same. ACCOUNT_WRITE is the cost of writing the recipient's balance leaf, so every call that sends value pays it. A CALL that sends value to a dead account as defined in EIP-161 pays an additional GAS_NEW_ACCOUNT as state gas. CALLCODE has no such cost because the recipient is the calling account itself. CREATE and CREATE2 used to pay a fixed GAS_CREATE of 32,000 with no cold or warm distinction, and this is now split into the execution gas CREATE_ACCESS (ACCOUNT_WRITE + COLD_ACCOUNT_ACCESS) and the state gas GAS_NEW_ACCOUNT. This definition does not match the 7,000 in footnote 3. The existing accounting was inconsistent to begin with, so the difference is left as is. SELFDESTRUCT pays COLD_ACCOUNT_ACCESS if the beneficiary is cold, regardless of the balance sent, and has no access cost if the beneficiary is warm. The WARM_ACCESS exemption from EIP-2929 is kept even when the beneficiary is the executing account itself or a precompile. Sending a positive balance to a dead account costs an additional ACCOUNT_WRITE, and GAS_NEW_ACCOUNT remains as state gas. EXTCODESIZE and EXTCODECOPY pay one more WARM_ACCESS on top of the existing access cost. After the account object (nonce, balance, codeHash, storageRoot) is read, the code size or bytecode is read again, and because the second read targets an account that is already warm, it is priced at WARM_ACCESS. DELEGATECALL, STATICCALL, BALANCE and EXTCODEHASH have no write component.

Measurement method: client benchmarks and a regression model

The gas values come from the time each execution client takes to actually run the benchmarks. Synthetic blocks that repeat a specific EVM operation are generated with varying operation counts and arguments (the EEST benchmark suite), and the Benchmarkoor tool measures block execution time and operation counts. All benchmarks were run multiple times per client on a snapshot the same size as mainnet in March 2026. The time of a single operation is estimated with a non-negative least squares regression (runtime = intercept + slope × operation_count). Only models with R² of at least 0.5 and a p-value below 0.05 are used. The time of the auxiliary (glue) opcodes attached to a test is subtracted as adjusted_slope = slope - sum(ratio_i * glue_runtime_i), but glue estimates that fail the criteria are not subtracted, and the result is clamped at 0 from below. When clients disagree, the value of the slowest client, which cannot be optimized away, is used as the network-wide baseline. The mapping is as follows: value_sent=0 in test_account_access(NO_CACHE) is COLD_ACCOUNT_ACCESS, value_sent=1 is COLD_ACCOUNT_WRITE, test_sload_bloated and test_sstore_bloated (write_new_value=False) are COLD_STORAGE_ACCESS, write_new_value=True is COLD_STORAGE_WRITE, and test_sload_same_key_benchmark and test_ext_account_query_warm are WARM_ACCESS. The write cost is obtained by subtracting the access estimate from the estimate that includes the write. The bloated tests target a contract with 10 gigabytes of storage, the same as the largest contract on mainnet. The state creation component prices state growth rather than execution time, so it is not estimated here.

Gas conversion formula and derived values

Execution time is converted to gas with raw_gas = ceil(anchor_rate * runtime_ms / 1000), based on a target throughput of 75 Mgas/s. anchor_rate is gas per second (75_000_000), runtime_ms is the per-operation time in milliseconds from the regression, and it is rounded up to an integer amount of gas. Write costs are obtained by subtracting the rounded-up estimates from each other. STORAGE_WRITE = max(0, COLD_STORAGE_WRITE - COLD_STORAGE_ACCESS), and ACCOUNT_WRITE = max(0, COLD_ACCOUNT_CODE_WRITE - COLD_ACCOUNT_CODE_ACCESS, COLD_ACCOUNT_NOCODE_WRITE - COLD_ACCOUNT_NOCODE_ACCESS). The rest are derived from the values chosen in the EIP: STORAGE_CLEAR_REFUND = (STORAGE_WRITE + COLD_STORAGE_ACCESS) * (4800/5000), ACCESS_LIST_STORAGE_KEY_COST = COLD_STORAGE_ACCESS - WARM_ACCESS, ACCESS_LIST_ADDRESS_COST = COLD_ACCOUNT_ACCESS - WARM_ACCESS, and CREATE_ACCESS = ACCOUNT_WRITE + COLD_ACCOUNT_ACCESS. WARM_ACCESS is subtracted from the two access list values because a slot or account listed in the access list is already warm when the transaction touches it, so WARM_ACCESS is charged again at that point. Without the subtraction, an item used only once would cost COLD_ACCESS + WARM_ACCESS, and using the list would always be more expensive. Optimizations that the EIP-7928 block-level access list makes possible, such as parallel disk reads, parallel transaction validation and state updates without execution, were already reflected by running the benchmarks on clients that implement those optimizations.

Compatibility and security considerations

This is a backward-incompatible gas repricing, so it requires a scheduled network upgrade. Wallets must be updated so that eth_estimateGas properly reflects the new gas parameters. Otherwise they may set too little gas and transactions may fail. RPC methods in node software such as eth_estimateGas must also include formulas with the new state access costs. Once wallets and RPC are updated, users can keep using them as usual. On security, the EIP states that changing state access costs may affect the usability of certain applications and that further analysis is needed to understand the effects on various dApps and user behavior.

Original status and core developer call decisions

The source status is Last Call, and the deadline (last-call-deadline) is 2026-11-01. It requires EIP-8037. The core developer call record is as follows. At ACDT #86 on 07.06, it was confirmed that after the freeze only parameter-only changes such as the gas costs in EIP-8038 and 2780 are allowed, and structural changes are blocked. This means constant values may be tuned but the design is not changed. At ACDT #90 on 08.03, it was decided to keep SLOAD at the current 2,100, set account writes to 9K and fix the anchor at 75 Mgas/s, and all EL clients approved. This means relative prices between opcodes are settled now and only the block limit will be adjusted going forward. At ACDE #243 on 08.13, the gas repricing figures were finalized, no spec change is needed, and the 200M gas limit for Glamsterdam was confirmed. Clients do not need to change their code. At ACDT #96 on 09.14, the SELFDESTRUCT beneficiary PR EIPs#12317 was approved as a clarification of the EIP wording, and neither the spec nor client behavior changes. At ACDE #240 on 07.02 and ACDT #102 on 10.26 there was only discussion and no decisions.

Original EIP · ← EIPs