EIP-7609 Lower the base cost of TLOAD/TSTORE (Decrease base cost of TLOAD/TSTORE)
Declined for Inclusion · Fees & gas · EIP status Stagnant · created 2024-02-01
Lowers the base gas cost of the transient storage opcodes TLOAD/TSTORE, and in exchange introduces a superlinear pricing model that adds extra cost the more slots are used, making common usage cheap and abuse expensive.
Why it is needed
Transient storage, introduced by EIP-1153, is storage space that is cleared when a transaction ends. In the original design, it was priced the same as warm access to regular storage, to keep the proposal simple and to address denial-of-service (DoS) concerns. However, transient storage does not interact with gas refund accounting, does not touch the actual database, and, unlike memory, does not need to be freshly allocated for each call. This means the current price is fundamentally higher than the real cost. In particular, if the first few slots of transient storage become cheap enough, languages could enable reentrancy protection by default at the language level, which addresses the largest and most damaging class of smart contract vulnerabilities, but the current price makes that too costly. This EIP changes pricing to charge extra gas in proportion to the amount allocated, so that the common case of using fewer than about 95 slots per contract becomes cheaper than today, while DoS using transient storage becomes prohibitively expensive.
What changes
Today
- TLOAD/TSTORE are priced the same as warm storage access, which is higher than their actual cost
- The price per slot is the same whether few or many slots are used
- The cost is too high for languages to enable reentrancy protection by default
After EIP-7609
- TLOAD costs 5 gas and TSTORE costs 8 gas plus an expansion cost
- Each time a new key is written, gas equal to the number of currently allocated slots is added, so usage gets more expensive the more is used
- The common case of using fewer than about 95 slots per contract becomes cheaper than today
- The total memory that can be allocated through transient storage actually decreases, which strengthens DoS protection
Who is affected
- Smart contract developers: Because the leading use case for transient storage, such as reentrancy protection, becomes cheaper, the gas cost of typical contracts that use few slots goes down.
- Language and compiler teams: If the first few slots become cheap enough, a design that enables reentrancy protection by default at the language level becomes possible.
- Client teams: Clients must implement gas calculation logic that factors the size of the transient storage mapping into the TSTORE cost.
In depth
Gas specification: G_LOW 5, G_MID 8, SLOPE 1
The gas cost of TLOAD is fixed at 5 gas (G_LOW). TSTORE costs 8 gas (G_MID) plus expansion_cost. expansion_cost is computed as 1 gas (SLOPE) x len(transient storage mapping) when the key is not yet in the transient storage mapping, and is 0 gas if the key already exists. That is, each time a new slot is allocated, an extra cost proportional to the number of slots allocated so far is added, so the total cost grows with the square of the slot count, a superlinear structure.
Benchmark basis
In benchmarking, TLOAD was measured to use CPU time similar to the MUL instruction, and TSTORE about 1.5 times that. G_low was chosen for TLOAD and G_mid for TSTORE to match these results. Unlike the current pricing, which is set equal to warm storage access, this is aligned more closely with the actual computational cost.
Why transient storage is overpriced
When EIP-1153 was developed, the price was set equal to warm storage loads and stores for two reasons: the conceptual simplicity of the proposal, and DoS concerns about over-allocating transient storage or the cost of reverting state on revert. However, transient storage does not interact with gas refunds or with the physical database, and unlike memory, which must be freshly allocated for each call, it needs to be allocated only once when the contract is loaded. The model in this EIP is cheaper than the current pricing in the common case of using fewer than about 95 slots per contract, while making DoS using transient storage prohibitively expensive.
DoS limit analysis
At a 30m gas limit, a single contract can allocate about 7,739 transient slots (the solution of x(x-1)/2*1 + 8*x = 30_000_000), for a total of 248KB. Using a strategy of calling a new contract each time the TSTORE cost exceeds the cold contract call cost (2600 gas) yields 2600 slots per contract and about 8.8 calls per transaction, so up to about 23,000 slots, 736KB in total, can be allocated. Compared with the current gas schedule, which allows allocating about 9.6MB of memory (30_000_000 / 100 * 32), the total is actually smaller, so this EIP imposes a stronger cap on transient storage resource usage. For reference, the memory that can be allocated in one transaction with SSTORE is 48KB (30_000_000 / 20_000 * 32). This cap is linearly proportional to the gas limit, which is a useful property when the block gas limit rises in the future.
Compatibility and prerequisites
No backwards compatibility issues were found. This proposal lists EIP-1153, which introduced transient storage itself, as a prerequisite (requires). The semantics of already deployed contracts do not change, only the gas cost calculation does.
Current status: Stagnant, dropped as a Hegotá candidate
The source status is Stagnant, meaning a proposal whose author activity has stopped. In the core developer calls as well, EIP-7609 was not accepted as a candidate at ACDE #243 on August 13, 2026, and because no champion (the person responsible for owning and pushing the proposal) was on the call, nixo agreed to contact the proposer and close the PR if that failed. Then at ACDE #244 on August 27, it was dropped from the Hegotá fork candidates because there was no champion to speak for it on the call. This means a proposal that nobody takes up falls out of consideration, and for now it has no fork inclusion schedule.