EIP-3298 Storage clearing refund and removal of the refund cap (Remove storage-clear refund and refund cap)
Hegota Considered for Inclusion · Fees & gas · EIP status Draft · created 2021-02-26
Removes the SSTORE refund given for clearing storage (STORAGE_CLEAR_REFUND) and the transaction refund cap, leaving only the refund for writes reverted within the same transaction.
Why it is needed
Gas refunds have existed since the Frontier era, when the chain launched. The goal was to give gas back for clearing storage that is no longer used, encouraging clients to keep state clean. However, the original argues that this incentive never worked in practice, and that the state growth problem is now handled not by a cleanup reward but by pricing state directly when it is created (EIP-8037). Meanwhile, the burden refunds place on the protocol remains. The refund counter must be capped at 20% of gas used (EIP-3529), and this cap becomes intricately entangled with the calldata floor gas (EIP-7623/7976) and the two-dimensional gas accounting of EIP-8037. SELFDESTRUCT refunds, EIP-7702 per-authorization refunds, and block-level accounting of refunds have already been removed by earlier EIPs. Only the SSTORE refund rules remain. The part that refunds writes reverted within the same transaction is legitimate net charging, while the clearing refund is a cross-transaction incentive that no longer has a justification. This EIP removes only the latter.
What changes
Today
- Clearing a storage slot whose original value is nonzero to 0 returns 11,616 gas per slot (STORAGE_CLEAR_REFUND)
- The total refund applies only up to 20% of the gas used before the refund (the EIP-3529 cap)
- This cap is entangled with the calldata floor and two-dimensional gas accounting, which makes the settlement rules complex
After EIP-3298
- Clearing storage gives no refund, because the state cost is already paid when the state is created
- Only writes (STORAGE_WRITE) that revert a value changed earlier in the same transaction are refunded
- The remaining refund cannot exceed fees already paid, so the full counter is deducted with no cap
Who is affected
- Apps and contracts that batch storage cleanup: The 11,616 gas per slot refund received for clearing a slot disappears, so the net cost rises by that amount
- Wallet and gas estimator developers: The clearing refund and refund cap logic must be removed from eth_estimateGas and fee calculation
- Client teams: One refund parameter, two refund rules, and the implementation of the cap's interaction with the floor and two-dimensional gas are gone, so settlement code becomes simpler
- Ordinary users: Ordinary transactions that do not clear storage see no change in cost. Refunds only take part in end-of-transaction settlement, and execution is unchanged
In depth
One refund remains: reverting a write within the same transaction
The STORAGE_WRITE refund rule of EIP-8038 remains. When the new value equals the original value and differs from the current value, that is, when a value changed earlier in the same transaction is reverted, STORAGE_WRITE is refunded. 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 that SSTORE executes. In the SSTORE case table of EIP-8038, only the entries containing STORAGE_CLEAR_REFUND are removed and the other entries are unchanged. The behavior of the refund counter is also unchanged. It accumulates during execution. It is journaled together with the call frame that granted the refund, so the share from a reverted frame is discarded, and it is applied once at end-of-transaction settlement.
Removal of STORAGE_CLEAR_REFUND (11,616)
STORAGE_CLEAR_REFUND is the parameter that succeeds SSTORE_CLEARS_SCHEDULE from EIP-3529, and its value is 11,616. This EIP removes this parameter from the gas schedule and also removes the two EIP-8038 refund rules that use it: the rule that gives a refund when clearing a slot whose original value is nonzero, and the rule that reverses that refund when such a cleared slot is restored. Meanwhile, EIP-8037's SSTORE charging rules and the charging and refilling of state gas are untouched. A state gas refill is not a refund, so it does not enter the refund counter.
Removal of the refund cap: deducting the full counter
The EIP-3529 cap is removed from EIP-8037's transaction settlement. What was tx_gas_refund = min(tx_gas_used_before_refund // 5, tx_output.refund_counter) simply becomes tx_output.refund_counter. After the refund, the EIP-7623 calldata floor still applies, so tx_gas_used = max(tx_gas_used_after_refund, calldata_floor_gas_cost), and the receipt's cumulative_gas_used uses the value after the floor is applied. Block-level accounting is unchanged. As in EIP-7778 and EIP-8037, the execution gas dimension counts the pre-refund value max(tx_gas_used_before_refund - tx_state_gas, calldata_floor_gas_cost). When EIP-8141 is enabled, frame transaction settlement likewise uses applied_refund = refund_counter and does not use MAX_REFUND_QUOTIENT.
Why it is safe without a cap: the refund is bounded by itself
The remaining refund can only return fees already paid in the same transaction. A slot can be restored to its original value and receive a refund only after it paid the write fee and its value changed, and each restoration returns exactly one fee. The refund counter therefore cannot exceed the sum of STORAGE_WRITE fees in the same transaction, and no cap is needed. The cap's other historical role, limiting block size, is handled by EIP-7778, which already removed refunds from block accounting. The security section states firmly that this safety rests on two properties: the refund is tied to fees in the same transaction, and the counter is journaled to follow reverts. A future EIP that adds a refund not backed by fees in the same transaction MUST either reintroduce the cap or prove an equivalent bound.
Rationale for removing the clearing refund
The clearing refund is the last remaining cross-transaction refund. Its purpose of encouraging cleanup lost its meaning after EIP-8037, which charges at the time state is created, and under EIP-8037 pricing it is too small compared with STATE_BYTES_PER_STORAGE_SET × CPSB to work either as an incentive or as a gas piggy bank. What remains is only specification and implementation burden: one parameter, two refund rules, and mainly the cap that exists to contain them. According to a note in the original, EIP-8038 raises STORAGE_CLEAR_REFUND to 11,616 in Glamsterdam, and this EIP removes it entirely, targeting the following fork.
Compatibility impact and test cases
This is gas repricing that breaks backward compatibility, so it requires a scheduled network upgrade. Refunds are applied only in the end-of-transaction settlement, so execution itself does not change and only the net cost changes. A transaction that clears a slot whose original value is nonzero no longer gets 11,616 gas back per slot, so applications that batched storage cleanup to chase refunds pay that much more. Gas estimators and wallets MUST remove the deletion refund and cap logic from eth_estimateGas and fee calculation. In the test table, x → y → x has a net cost of 0, and x → 0 pays STORAGE_WRITE with no refund. It also requires verifying a transaction that clears many slots (no refund), a case where the refund exceeds 20% of gas used before the refund (confirming the deduction applies without the cap), a case that hits the calldata floor, and EIP-7778 block accounting.
Current status and fork discussion
This EIP is in Draft status, so its content may still change. According to the call records, it was accepted as a Hegota candidate (PFI) at ACDE #243 on 08.13, and moved up to the Considered for Inclusion (CFI) stage for Hegota at ACDE #246 on 09.24, together with EIP-7906, EIP-8250, EIP-8272, EIP-7668, EIP-8253, EIP-8131 and others.