This Meta EIP documents all the proposals for Glamsterdam related to the gas repricing effort. The goal of this effort is to harmonize gas costs across the EVM, thereby reducing the impact of specific bottlenecks on scaling. Proposals include changes to the cost of single EVM operations, as well as bigger changes to the gas model. This Meta EIP is purely informational and does not aim to have an active role in the governance process for the Glamsterdam fork. Instead, it serves as a directory for all repricing-related proposals, helping to organize the work and keeping the community informed about the status of each EIP.
Motivation
The main objective of the Glamsterdam fork is to improve L1 scalability. A crucial aspect of this initiative is to create a better alignment between gas costs and actual resource usage. Currently, the gas model often prices operations incorrectly, resulting in inefficiencies and unintended incentives. For instance, within the pure compute operations, there is a high variance in execution time per gas unit, which indicates that a single unit of computation is not priced equally across the various opcodes.
By standardizing gas costs across EVM operations and other resources, we can reduce bottlenecks and enhance the utilization of EVM resources, which will subsequently enable further scalability. The EIPs listed below constitute a significant first step in that direction. We expect that further iteration will be necessary in future hardforks.
Specification
The following table lists all EIPs related to repricings that are being discussed in the scope of the Glamsterdam fork. There are three types of EIPs in this list:
Broad harmonization. These EIPs reprice a class of operations with the goal of harmonizing them and removing single bottlenecks.
Pricing extension. These EIPs make targeted changes to a specific opcode or component of the gas model, usually coupled with a new mechanism.
Supporting. These EIPs are not directly doing a repricing, but instead introduce a change that support other repricing EIPs or enhance the scalability potential of repricings.
Decompose the flat intrinsic transaction cost into explicit primitives priced to match the resources a transaction actually consumes.
Broad harmonization
Multi-resource
Decompose flat 21,000 into TX_BASE_COST (12,000) + COLD_ACCOUNT_ACCESS (3,000) + TX_VALUE_COST (6,000); split the primitives into state-independent intrinsic gas (the sole validity input) and state-dependent runtime gas, charging STATE_BYTES_PER_NEW_ACCOUNT × CPSB (183,600) state gas at runtime for value transfers that create an account
Prevent Block Gas Limit Circumvention by Excluding Refunds from Block Gas Accounting.
Pricing extension
General Accounting
No opcode repricing; excludes gas refunds (e.g. SSTORE clearing) from block gas accounting. Combined with EIP-8037, the exclusion applies to the execution-gas dimension only: state-gas refills reverse charges for state that was never durably created and stay netted out
Empirical analysis of EVM compute operation run times (Informational); concludes no compute gas cost needs repricing at the target throughput.
Broad harmonization
Compute
No changes: with EIP-7928 optimizations in place, all examined compute opcodes and precompiles already meet the 100 Mgas/s target at their current cost
Harmonization, increase and separate metering of state creation gas costs to mitigate state growth and unblock scaling.
Broad harmonization
State
All increase via a fixed CPSB (1,530 gas/byte), metered in a separate state-gas dimension: GAS_CREATE, GAS_CODE_DEPOSIT, GAS_NEW_ACCOUNT, GAS_STORAGE_SET, PER_AUTH_BASE_COST, PER_EMPTY_ACCOUNT_COST
Gas parameters and variables are increased to a factor of REBASE_FACTOR to reduce rounding errors without major changes to the EVM.
Supporting
N/A
Rationale
Gas cost changes by operation
The following tables summarize the preliminary gas cost changes. Numbers are not yet finalized and will be subject to change.
Compute Opcodes and Precompiles — EIP-7904 (no changes)
EIP-7904 is now Informational and recommends no repricing. Earlier revisions proposed raising the cost of a set of compute opcodes and precompiles, but re-running the benchmark and estimation pipeline against clients that include the parallel-execution optimizations unlocked by EIP-7928 (Block-Level Access Lists) shows those operations now clear the 100 Mgas/s throughput target at their current gas costs. Every compute opcode and precompile examined is therefore left unchanged.
EIP-8037 introduces a fixed cost per state byte, CPSB = 1,530 (derived from a 150M reference block gas limit), and meters state creation in a separate state-gas dimension. The new-state byte counts are 120 per account, 64 per storage slot, and 23 per EIP-7702 authorization indicator. The “New state gas” column is charged to the state-gas dimension; the “New execution gas” column accompanies it in execution gas.
Operation
Opcodes Affected
Current
New state gas
New execution gas
Direction
GAS_CREATE
CREATE, CREATE2, create txs
32,000
120 × CPSB (183,600)
CREATE_ACCESS
increase
GAS_CODE_DEPOSIT
CREATE, CREATE2, create txs
200/byte
CPSB/byte (1,530/byte)
6 × ceil(len/32) (hash)
increase
GAS_NEW_ACCOUNT
CALL* to new accounts, SELFDESTRUCT
25,000
120 × CPSB (183,600)
0
increase
GAS_STORAGE_SET
SSTORE (0 → non-zero)
20,000
64 × CPSB (97,920)
0
increase
PER_EMPTY_ACCOUNT_COST
EIP-7702 auth
25,000
120 × CPSB (183,600)
ACCOUNT_WRITE
increase
PER_AUTH_BASE_COST
EIP-7702 auth
12,500
23 × CPSB (35,190)
EXECUTION_PER_AUTH_BASE_COST
increase
Transaction-Level Costs
Parameter
Current
New
Direction
EIP
Intrinsic base (plain transfer to existing account)
PER_EMPTY_ACCOUNT_COST (25,000) intrinsic, refunded down to PER_AUTH_BASE_COST (12,500) when the authority already exists
EXECUTION_PER_AUTH_BASE_COST (7,816) intrinsic; state-dependent charges at runtime: ACCOUNT_WRITE on first write to the authority, 183,600 state gas for a non-existent authority, 35,190 state gas for net-new delegation bytes
Two further transaction-level changes come from EIP-8037’s separate state-gas dimension. EIP-7825’s TX_MAX_GAS_LIMIT applies to execution gas only, with state gas bounded by tx.gas alone, so large contract deployments are no longer capped by the per-transaction gas limit. The system-call gas limit is raised from 30,000,000 to 30,000,000 + STATE_BYTES_PER_STORAGE_SET × CPSB × SYSTEM_MAX_SSTORES_PER_CALL, preserving the existing execution margin for system contracts under the higher state creation costs.