EIP-8374 Keep warm access after a revert (Persist Warm Access Sets Across Reverts)
Hegota Declined for Inclusion · Fees & gas · EIP status Draft · created 2026-08-06
When a call fails and is reverted, the warm status of the addresses and storage keys read inside it is not erased. If the same transaction reads them again, it pays the cheap warm cost instead of the expensive cold cost.
Why it is needed
When Ethereum reads an address or storage slot for the first time in a transaction, it charges a high price (cold), and from the second read on it charges a low price (warm). This is because the node incurs a real cost when it first pulls the data out of the database. Under the current rule (EIP-2929), if a call fails and is reverted, the access records for what was read inside that call are erased along with it. However, a revert only cancels state changes. It does not evict data that has already been read from the node's cache. If the same transaction reads that data again, it actually finishes cheaply, but the fee is charged as high as if it were the first read. This EIP aims to remove this mismatch between real cost and fee, and to simplify client implementations by detaching access records from the revert mechanism.
What changes
Today
- When a call fails, the warm records of the addresses and storage keys read inside it are rolled back to the state just before the call.
- If data read inside a failed call is read again from outside, the cold cost is paid again.
- Clients must put access records into the journal like state changes and include them in the revert mechanism.
After EIP-8374
- However a call ends, an address or storage key that has become warm stays warm until the transaction ends.
- If data read inside a failed call is read again from outside, only the warm cost is paid.
- Access records are only appended during a transaction and do not enter the journal or the checkpoint and revert mechanism.
Who is affected
- Users: The gas cost of a transaction that rereads the same data after a failed inner call goes down or stays the same. No transaction becomes more expensive.
- Contract developer: Code that assumes the exact gas cost of an access after a revert may consume a different amount of gas.
- Client teams: The access sets can be detached from the journal and the checkpoint and revert mechanism, which simplifies implementations. Adoption requires a hard fork.
In depth
Removing access set rollback
EIP-2929 tracks accessed addresses and storage keys with two transaction-scoped sets, accessed_addresses and accessed_storage_keys, and restores both sets to their pre-call state when a call frame reverts or halts with an exception. This EIP removes that rollback starting at the fork block. However a call frame ends, other than normal completion, the two sets MUST NOT be rolled back. Every entry added while the frame runs, including entries added by sub-calls, MUST remain in the sets. Once an address or key enters a set, it stays warm until the transaction ends.
Order of paying the cold cost and adding to the set
For a cold account access or cold storage access, the cold access cost MUST be paid first, and only then is the address or storage key added to the set. If there is not enough gas to pay that cost, the entry MUST NOT be added. Once the cost has been paid, the entry MUST remain in the set even if a later charge or check within the same instruction fails. The rules for entries initialized at the start of a transaction and for addresses added by CREATE and CREATE2 stay exactly as specified in EIP-2929.
Why rollback is not needed
The source text explains that the access sets are a metering device that measures cost, not observable state. Reverting a frame cannot make the client forget bytes it has already read, so rolling back the sets protects nothing. Making the sets append-only charges the second access a fee equal to its real cost, and removes the only part of the journal that was imitating a cache rather than state. An alternative is to keep the rollback and discount repeated cold accesses, but the source text sees this as merely adding a third price tier, no better than leaving the entry warm.
Backward compatibility and gas cost changes
This EIP requires a hard fork. After the fork, some accesses that were previously charged as cold are charged as warm, so transactions become cheaper or stay the same, and none becomes more expensive. This case arises when an outer frame rereads an address or key that a failed inner call had read. However, a contract that depends on the exact gas cost of an access after a revert may consume a different amount of gas.
Test cases
Based on the access costs in EIP-2929, the source text lists four cases. First, if frame A DELEGATECALLs frame B, and B does a cold SLOAD of A's storage slot s and then reverts, A pays the warm storage access cost when it next reads s. Second, if A calls B, and B pays the cold BALANCE cost for address a and then halts from lack of gas, A pays the warm account access cost when it accesses a. Third, if B runs out of gas before paying the cold access cost for address a, A's access pays the cold account access cost. Fourth, the state changes of the reverted frame stay reverted and only the access set entries remain. When EIP-8038 is active, WARM_STORAGE_READ_COST, COLD_SLOAD_COST and COLD_ACCOUNT_ACCESS_COST are renamed WARM_ACCESS, COLD_STORAGE_ACCESS and COLD_ACCOUNT_ACCESS respectively.
Security considerations
If warm status persists across reverts, a transaction can pre-warm addresses and storage keys inside a frame that it will later revert, and then access them cheaply afterward. The source text explains that this is not a new capability. The access list of an EIP-2930 transaction already changes the warm or cold status of arbitrary addresses and storage keys in the same way, before execution even starts. In both cases the cold cost of each entry that becomes warm is paid once within the transaction, so the total work charged still covers the client's real loading cost.
Status and fork discussion
This EIP is in Draft status and was written by Dragan Rakita (@rakita) on 2026-08-06. Because the source status is Draft, the detailed rules of the specification may still change. On the core developer calls, it was accepted as a Hegota candidate (PFI) at 08.13 ACDE #243. It was introduced as a proposal not to erase the warm status of the access list when a call fails. It was later declined for the Hegota candidate list (DFI) at 10.08 ACDE #247, because support was lukewarm and a deep change at the fork boundary was judged not worth its complexity.