Ethereum Transient Storage: How EIP-1153 TLOAD and TSTORE Work

A smart contract sometimes needs to leave itself a note for later calls in the same transaction—but keeping that note forever would waste persistent state. Ethereum transient storage provides that short-lived workspace. It belongs in blockchain basics because its lifetime sits between memory, which is fresh for each call frame, and storage, which survives across transactions.

EIP-1153 introduced the TLOAD and TSTORE opcodes for this job. The mechanism can make patterns such as reentrancy locks more efficient, but “automatically cleared” does not mean “automatically safe.” This guide follows the finalized protocol specification and current Solidity documentation, separates implemented rules from proposals, and shows what developers should verify.

What Ethereum transient storage is

Think of a transaction as a group using a meeting room. Memory is each participant's scratchpad: a new one appears for every message call. Persistent storage is the filing cabinet: its contents remain after everyone leaves. Transient storage is the shared whiteboard assigned to one contract for the entire meeting. Calls belonging to that contract can read the whiteboard, but Ethereum wipes it when the transaction ends.

EIP-1153 defines transient storage as a contract-owned, word-addressed key-value area. Its values behave much like storage during execution, including revert behavior, but every value is discarded at the end of the transaction. It is not serialized into Ethereum's persistent state.

Opcode	Hex	Action	EIP-1153 gas cost
`TLOAD`	`0x5c`	Read one 32-byte word from a transient slot	100 gas
`TSTORE`	`0x5d`	Write one 32-byte word to a transient slot	100 gas

These costs come from the finalized EIP-1153 specification. Draft proposals may suggest different future pricing, but developers should not present proposed numbers as active network rules.

How the transaction-scoped lifetime works

Transient storage is broader than EVM memory and narrower than persistent storage. Four boundaries matter.

It survives calls within one transaction

If contract A writes a transient slot, a later frame executing as contract A in the same transaction can read it. This helps when control travels through another contract and returns. Ordinary memory cannot provide that shared contract-level channel because every message-call frame receives fresh memory.

It resets after the whole transaction

The reset happens at transaction end, not when one function returns. A nonzero value can therefore affect a later call to the same contract inside a multicall or callback sequence. Developers should clear a temporary lock when its intended scope ends unless leaving it set for later same-transaction calls is deliberate.

Reverts roll writes back

When a call frame reverts, transient writes made in that frame and its reverted inner calls roll back, mirroring persistent storage semantics. A successful outer frame retains its earlier transient values.

Ownership follows execution context

For a normal CALL, the callee owns the transient storage being accessed. Under DELEGATECALL, ownership follows the caller whose context is executing, just as it does for persistent storage. This distinction is especially important for upgradeable proxy contracts, libraries, and shared implementations.

Transient storage vs memory vs storage

Property	Memory	Transient storage	Persistent storage
Lifetime	One message-call frame	One transaction	Across transactions
Addressing	Byte-addressed	32-byte word slots	32-byte word slots
Shared across a contract's frames	No	Yes	Yes
Revert-aware	Frame disappears	Writes roll back	Writes roll back
Included in persistent chain state	No	No	Yes

Transient storage is not “cheap memory.” It has storage-like ownership and slot behavior, and its values may remain visible after a function returns. Use memory for calculations that belong to one frame. Use persistent storage for state that future transactions must observe. Use transient storage only when multiple frames in the current transaction need contract-owned temporary state.

How Solidity exposes EIP-1153

The official Solidity contracts documentation supports the transient keyword on state variables. Solidity requires an EVM target of Cancun or newer, because earlier EVM versions do not have TLOAD and TSTORE.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;
 
contract TransientGuard {
    bool transient locked;
 
    modifier nonReentrant() {
        require(!locked, "reentrant call");
        locked = true;
        _;
        locked = false;
    }
}

Current high-level Solidity support allows value-type state variables in transient storage. Reference types such as arrays, mappings, and structs are not currently supported through that declaration syntax. Transient variables also cannot be initialized at declaration: creation happens inside a transaction, and the value would be cleared when that transaction ends.

Storage and transient storage use independent address spaces. Adding a transient variable does not shift ordinary storage slots, although transient variables still need distinct names and have their own layout. The compiler's standard JSON output can report transientStorageLayout for review.

Important

Compile for the actual deployment chain. Bytecode containing TLOAD or TSTORE is not portable to a network that has not enabled the Cancun EVM rules.

The canonical reentrancy-lock use case

A reentrancy lock must remain visible while a function makes an external call and an attacker tries to enter again before the original execution completes. That requires communication across call frames. Historically, contracts used persistent SLOAD and SSTORE, then cleared the lock before returning.

EIP-1153 provides a transaction-scoped location for the same coordination without writing long-lived state. The pattern can reduce execution cost because no persistent disk state or gas-refund accounting is required. It does not remove the need for correct control flow:

Check the lock before sensitive effects.
Set it before any untrusted external interaction.
Execute the protected body.
Clear it when later calls in the same transaction should be allowed.
Test nested calls, multicalls, callbacks, failure paths, and proxy execution context.

The lock is one layer, not a proof that a contract is secure. Checks-effects-interactions, pull-based transfers, narrow external calls, access control, and adversarial testing can still matter. Review the underlying smart-contract model before treating a modifier as a complete defense.

Other valid use cases

The EIP lists several patterns that need temporary communication across frames:

single-transaction token approvals;
callback accounting that must balance before the transaction finishes;
metadata passed through proxy execution;
a fee or permission unlocked only for the current transaction; and
constructor data shared by a factory while deriving CREATE2 addresses.

These are architectural building blocks, not recommendations to replace every temporary variable. Ask whether a value must be shared by multiple frames owned by the same execution context during one transaction. If not, calldata, return data, stack variables, or memory may be simpler.

Risks and limitations

The reset boundary is easy to misunderstand

Transient values do not clear after each external function. A batch router can call the same contract again before the transaction ends and observe an uncleared slot. This can break composability or intentionally influence later operations.

Delegatecall changes whose slots are used

An implementation reached through DELEGATECALL accesses the proxy's transient storage. Different modules can collide if they choose the same transient slot. High-level compiler layout reduces accidental collisions within one compiled hierarchy, but hand-written assembly and modular proxy systems require explicit namespacing.

Static calls cannot write

TLOAD is allowed under STATICCALL; TSTORE causes an exception because it modifies transaction-scoped state. A function's temporary data does not make it compatible with a static execution context.

Compiler versions matter

The Solidity known-bugs list is part of deployment diligence. Solidity documents a high-severity transient-storage clearing-helper collision affecting particular via-IR builds from 0.8.28 through 0.8.33 and fixed in 0.8.34. Check the current official compiler bug list, pin the compiler, and verify whether your settings meet listed conditions.

Cheaper state can still be abused

Each transient write consumes node memory and must support rollback. EIP-1153 prices the operations above memory, and later repricing proposals remain separate protocol work. Do not assume unlimited transient allocation is harmless or that a future draft's gas schedule is already active.

Developer checklist

FAQ

Did EIP-1153 create permanent Ethereum state?

No. Transient values are discarded after each transaction and are not committed as persistent contract storage.

Does transient storage clear when a function returns?

No. It remains available to the owning contract's later frames until the entire transaction finishes, unless code overwrites or clears it first.

Can one contract read another contract's transient slots?

No. Ownership is contract-scoped like persistent storage. Call context rules, especially DELEGATECALL, determine which contract owns the active slots.

Is TSTORE allowed in a static call?

No. The EIP specifies that TSTORE in STATICCALL raises an exception. TLOAD is allowed.

Can Solidity declare transient mappings or arrays?

Not with current high-level transient state-variable support. Official documentation limits it to value types.

Primary sources

Use the shortest-lived state that fits

Transient storage is a contract-owned whiteboard for one transaction. It gives separate call frames a shared temporary channel while avoiding permanent state, but its transaction-wide lifetime, revert behavior, and delegatecall ownership must be designed deliberately. Choose it when those exact semantics fit—not merely because it is cheaper than persistent storage.

This article is educational, not financial advice. Smart-contract interactions are irreversible and crypto assets are volatile; test on the correct network, use only funds you can afford to lose, verify current primary documentation, and do your own research (DYOR).