EIP-8374 draft would keep accessed addresses and storage keys warm after a call frame reverts
Victoria Shinder2 min readA new draft, EIP-8374 "Persist Warm Access Sets Across Reverts", was merged into the Ethereum EIPs repository on 15 October 2026 by the repository's bot. Written by Dragan Rakita, it is a Core Standards Track proposal that requires a hard fork; its status is Draft, and discussion runs on Ethereum Magicians.
What it changes. Since EIP-2929, the EVM tracks two transaction-scoped sets, accessed_addresses and accessed_storage_keys, to decide whether an access is charged at the cold or the warm price. When a call frame reverts or halts exceptionally, both sets are rolled back to their state before the call. EIP-8374 removes that rollback: once an address or storage key has been added, it stays warm for the rest of the transaction, whatever happens afterwards. Entries added by a frame's subcalls stay as well.
Why. The draft argues that warm and cold pricing exists to reflect the client's real cost of loading state, a cost paid on the first read from the database. A revert undoes state changes but does not unload the data, which remains in the client's caches; charging cold prices for a second access after a revert therefore prices work that does not happen. It adds an implementation benefit: access sets become append-only and no longer need to take part in the state journal or the checkpoint-and-revert machinery. A rejected alternative — keeping the rollback but discounting repeated cold accesses — would, the author writes, add a third pricing tier for no gain.
The exact rule. The cold charge must be paid before an entry is added; if there is not enough gas to pay it, the entry is not added. Once paid, the entry remains even if a later charge or check in the same operation fails. The draft's test cases make this concrete: if frame B performs a cold SLOAD of a slot in A's storage via DELEGATECALL and reverts, A's next load of that slot pays the warm price; if B runs out of gas before paying a cold charge, A still pays cold. State changes in a reverted frame stay reverted — only the access-set entries persist.
Compatibility and security. After the fork, some accesses that used to be charged cold become warm, so transactions get cheaper or stay the same; none becomes more expensive. Contracts that depend on exact gas costs of accesses after a revert may see different consumption. On security, the draft notes that a transaction could warm entries inside a frame that is then reverted and use them cheaply later, but argues this is not new: an EIP-2930 access list already lets a transaction change the warm or cold status of arbitrary addresses and keys before execution, and in both cases the cold cost of each entry is paid once.
Source: EIP-8374 as merged on 15 October 2026 — https://github.com/ethereum/EIPs/commit/6c6c83f427bb2f22b