ethereum · abc-123-c · May 23, 2026 · May 23, 2026 · Jun 10, 2026 · Jun 10, 2026
@@ -45,6 +45,18 @@ Upon activation of this EIP, the following parameters of the gas model are intro
 
 ³: 7,000 = `GAS_CREATE` (32,000) - `GAS_NEW_ACCOUNT` (25,000)
 
+### Addition of `state_access_gas_reservoir`
+
+This EIP additionally introduces a new counter, `state_access_gas_reservoir`. This counter accumulates refunds associated with state access or state update operations and is not subject to the 20% refund cap introduced by [EIP-3529](./eip-3529.md).
+
+Refunds eligible to accumulate in this counter exclude `STORAGE_CLEAR_REFUND`; such refunds continue to be refilled to the transaction refund counter and remain subject to the existing 20% cap.
+
+At the start of transaction execution, `state_access_gas_reservoir` is initialized to `0`. Future protocol upgrades may initialize this counter with a non-zero value once multidimensional fee accounting is finalized.
+
+During transaction execution, any operation that consumes state access or state update gas costs MUST first draw from `state_access_gas_reservoir` before consuming gas from `gas_left` (where `gas_left` is defined by [EIP-8037](./eip-8037.md)).
+
+Additionally, any refund associated with state access or state update operations MUST be refilled to `state_access_gas_reservoir`.
+
 ### `SSTORE` pricing
 
 In addition, the `SSTORE` cost formula is updated to include the following independent costs:
@@ -55,25 +67,24 @@ In addition, the `SSTORE` cost formula is updated to include the following indep
 
 Refunds are also updated as follows:
 
-1. `STORAGE_CLEAR_REFUND` is refunded if the original value is non-zero, the current value is non-zero and the new value is zero.
-2. `STORAGE_WRITE` is refunded if the original value is the same as the new value.
+`STORAGE_CLEAR_REFUND` is refunded if the original value is non-zero, the current value is non-zero and the new value is zero.
 
 These refunds go to the transaction's refund counter and are capped to 20% of the total gas used by the transaction, as per the current refund mechanism.
 
 The rules for state creation cost charges and refills are addressed in [EIP-8037](./eip-8037.md).
 
 Cases and their corresponding costs are detailed in the table below:
 
-| Original value | Current value | New value | Access status | Description | Regular-gas charges/refunds | State-gas charges/refills |
+| Original value | Current value | New value | Access status | Description | Regular-gas charges/refills/refunds | State-gas charges/refills |
 | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
 | 0 | 0 | x | Cold | New slot | `COLD_STORAGE_ACCESS` + `STORAGE_WRITE` charged | `GAS_STORAGE_SET` charged |
 | 0 | 0 | x | Warm | New slot | `WARM_ACCESS` + `STORAGE_WRITE` charged | `GAS_STORAGE_SET` charged |
-| 0 | x | 0 | Warm | Cleared slot, zero at transaction start | `WARM_ACCESS` charged, `STORAGE_WRITE` refunded | `GAS_STORAGE_SET` refilled |
+| 0 | x | 0 | Warm | Cleared slot, zero at transaction start | `WARM_ACCESS` charged, `STORAGE_WRITE` refilled | `GAS_STORAGE_SET` refilled |
 | x | x | 0 | Warm | Cleared slot, non-zero at transaction start | `WARM_ACCESS` charged, `STORAGE_CLEAR_REFUND` refunded | no state-gas adjustments |
 | x | x | y | Cold | Existing slot, updated to new value | `COLD_STORAGE_ACCESS` + `STORAGE_WRITE` charged | no state-gas adjustments |
 | x | x | y | Warm | Existing slot, updated to new value | `WARM_ACCESS` + `STORAGE_WRITE` charged | no state-gas adjustments |
 | x | y | z | Warm | Existing slot, written to again | `WARM_ACCESS` charged | no state-gas adjustments |
-| x | y | x | Warm | Existing slot, value reset | `WARM_ACCESS` charged, `STORAGE_WRITE` refunded | no state-gas adjustments |
+| x | y | x | Warm | Existing slot, value reset | `WARM_ACCESS` charged, `STORAGE_WRITE` refilled | no state-gas adjustments |
 
 ### Account access pricing
 
@@ -225,6 +236,20 @@ Differently from other account read operations, `EXTCODESIZE` and `EXTCODECOPY`
 
 [EIP-2926](./eip-2926.md) proposes to change how code is stored in the state trie. One of the changes of this proposal is to include the code size as a new field in the account object (`codeSize`). With this change, the code size can be directly accessed with a single read to the database and thus `EXTCODESIZE` should maintain its previous cost formula, without including the additional `WARM_ACCESS`.
 
+### Why add `state_access_gas_reservoir`
+
+This more accurately reflects the intended purpose of gas refunds.
+
+Accumulations in the transaction refund counter should be reserved for gas originating outside the current transaction itself (for example, `STORAGE_CLEAR_REFUND`, whose value originates from a prior state-creating transaction), or for mechanisms intended to avoid unexpected changes to the gas budget available to individual execution frames.
+
+State access refunds do not fall into either category. They originate from gas previously paid within the same transaction, and cannot increase the gas budget already allocated to any execution frame, meaning they remain constrained by the semantics introduced in [EIP-2200](./eip-2200.md).
+
+Future upgrades may further extend this mechanism into a separate fee dimension, thereby increasing transaction throughput.
+
+This approach also provides long-term benefits by removing historical failure modes where legacy contracts forwarding limited gas could unexpectedly fail following opcode repricings. [EIP-2930](./eip-2930.md) partially addressed this backward compatibility issue through optional access lists. However, the introduction of [EIP-7928](./eip-7928.md) makes that approach increasingly obsolete, and [EIP-7981](./eip-7981.md) is expected to remove the optional access list discounts entirely.
+
+Under this model, state access costs are paid dynamically during transaction execution rather than being statically declared at transaction initialization.
+
 ## Backwards Compatibility
 
 This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.