EIP-8372 Normalized State Gas Limit
Proposed for Inclusion · Fees & gas · EIP status Draft · created 2026-08-06
Gives the state gas of EIP-8037 its own limit, separate from the block limit, and normalizes its usage when computing block gas used. At the fork, the cost per state byte (CPSB) and the limit ratio are calibrated once to the demand estimate.
Why it is needed
EIP-8037 adds a separate account called state gas for operations that leave permanent data on the blockchain, such as contract deployment or storage. It uses the same block limit as execution gas and takes the larger of the two as the block's gas usage. In this design, CPSB (cost per state byte), the price of one byte of state, determines the amount of state that corresponds to the 50% utilization target. However, there is no guarantee that users will spend half of the gas budget on state creation. If demand is lower than expected, less state is created than intended. If demand is higher than expected, state gas becomes the bottleneck and suppresses execution gas consumption as well. Instead of the longer-term direction of continuously adjusting price and limit to demand (EIP-7999), this proposal takes a simpler approach of calibrating only once, at the hard fork.
What changes
Today
- Execution gas and state gas share the same block limit, and the larger cumulative value becomes the block's gas_used
- If state demand is lower than expected, less state is created than the target
- If state demand is higher than expected, state gas becomes the bottleneck and execution gas is used less
After EIP-8372
- State gas gets its own raw limit, set as a fixed share of the block gas limit (STATE_GAS_LIMIT_SCALE%)
- The larger of the normalized state gas usage and the execution gas becomes the block's gas_used
- At the fork, CPSB and the limit ratio are calibrated together to the demand estimate, and they stay fixed after activation
Who is affected
- Client teams: Block validation must implement the state gas limit check and the normalized gas_used computation. This is a consensus-affecting change, so it requires a scheduled network upgrade.
- Block builders: When including transactions, the remaining state gas must be computed from the new CPSB and the raw state gas limit.
- Wallet & app developers: Gas estimation tools must reflect the new CPSB and the normalized block-level accounting for fee predictions to be correct.
- Users: The per-byte price of state-creating operations is adjusted to match demand, so state creation and ordinary execution push each other out less.
In depth
Two failure modes of EIP-8037
EIP-8037 gives execution gas and state gas the same block limit and uses the larger cumulative value as the block's gas_used. CPSB therefore determines the number of state bytes that corresponds to the 50% state gas target. At the chosen CPSB, state demand may be lower or higher than the level at which both resources approach the common 50% target together. If it is relatively low, less state is created than intended. If it is relatively high, state gas becomes the bottleneck and execution gas consumption is suppressed. Because the two gases share one common base fee, a mismatch between price and demand affects not only the amount of state growth but also which dimension reaches the common target first and whether the other dimension is underused.
Parameters
Updates the parameter table of EIP-8037. CPSB is TBD, STATE_GAS_LIMIT_SCALE is TBD, and STATE_GAS_LIMIT_SCALE_DENOMINATOR is 100. CPSB and STATE_GAS_LIMIT_SCALE must be positive integers, and STATE_GAS_LIMIT_SCALE specifies the raw state gas limit as a percentage of the block gas limit. The denominator of 100 gives calibration steps of one percentage point, which is fine enough given the uncertainty in the demand estimate.
Transaction validation changes
The state_gas_available definition in EIP-8037 is updated. The raw state gas limit is computed as state_gas_limit = block_env.block_gas_limit * STATE_GAS_LIMIT_SCALE // STATE_GAS_LIMIT_SCALE_DENOMINATOR, and the remaining state gas is computed as state_gas_available = state_gas_limit - block_output.block_state_gas_used. The assumption that the state gas limit equals the block gas limit no longer holds, and a separate limit set as a ratio of the block gas limit becomes the reference.
Block-level gas accounting and normalization
The block-level gas_used computation changes. Raw state gas usage is first normalized with normalized_block_state_gas_used = (block_output.block_state_gas_used * STATE_GAS_LIMIT_SCALE_DENOMINATOR) // STATE_GAS_LIMIT_SCALE, and then gas_used = max(block_output.block_execution_gas_used, normalized_block_state_gas_used) is set. There are two block validity conditions. Raw state gas usage must be at most state_gas_limit, and gas_used must be at most the block gas limit. The block_state_gas_used counter continues to be tracked in raw state gas units, and no new block header fields or transaction fields are introduced.
Calibration methodology
A single best-effort calibration is made at activation. First target_state_growth_per_year and expected_block_gas_limit are set, and then baseline_cpsb = expected_block_gas_limit * blocks_per_year // (2 * target_state_growth_per_year) is derived. blocks_per_year and baseline_cpsb are analysis values, not consensus parameters. The expected demand at baseline_cpsb is compared with the target to choose one of three calibrations. If demand matches the target, no scaling is needed. If it is lower, CPSB and the raw state gas limit are reduced together, and if it is higher, they are increased together. The actual CPSB is chosen using the observed demand elasticity so that expected state growth is close to the target, and the limit ratio is set with STATE_GAS_LIMIT_SCALE = CPSB * STATE_GAS_LIMIT_SCALE_DENOMINATOR // baseline_cpsb. Changing CPSB and the raw limit proportionally preserves the normalized state gas allotted to the target number of state bytes, so the effect is to leave the allocation of block space unchanged and adjust only the price to match demand. This can be seen as a passive, one-time analogue of EIP-8075, which adjusts price and limit dynamically with demand.
Compatibility and Security Considerations
This changes consensus-critical block validation rules, so it requires a scheduled network upgrade. After activation, a client that has not implemented the new rules may reach different conclusions on transaction inclusion, block validity, and the header gas_used value. Pre-activation blocks, transaction formats, the reservoir model of EIP-8037, per-transaction gas accounting, and receipt semantics do not change. The largest risk is parameter miscalibration. A wrong calibration can move the system from one failure mode to the other and cannot be fixed without a later hard fork, so the chosen parameters should be stress-tested across a plausible range of demand elasticities. However, because the raw limit and CPSB move proportionally, the maximum state byte capacity stays nearly constant regardless of the calibration, up to integer rounding.
Status and Fork Discussion
This EIP is in Draft status, so its content may still change, and the key constants CPSB and STATE_GAS_LIMIT_SCALE are also TBD. In core developer calls, it was accepted as a Hegotá candidate at ACDE #243 on August 13, 2026. The aim is to calibrate the price once at the fork to match state creation demand after Glamsterdam. At ACDE #245 on September 10, it was decided not to DFI it but to decide together with EIP-8368 (CPSB readjustment), which has broad support, and the call noted that the decision can be made after observing demand response following the Glamsterdam rollout. At ACDE #246 on September 24, it was decided to keep it as PFI together with EIP-8368 until mainnet Glamsterdam data has accumulated for at least 30 days after the fork. This means no decision will be made without measured data.