Transient Storage

Data stored in the tstore operation persists only for the duration of a single transaction. It is automatically and gaslessly cleared at the end of the transaction's execution, regardless of success or failure. This eliminates the need for manual cleanup and associated gas costs, making it ideal for temporary data like reentrancy locks, intermediate computation results, or data passed between internal calls.

Transient storage provides significant gas savings compared to persistent storage (sstore). Writing (tstore) and reading (tload) cost only 100 gas each, mirroring warm storage access. The key savings come from zero-cost cleanup; deleting persistent storage via sstore to 0 costs gas, while tstore cleanup is free. This makes it optimal for data that is written and deleted within the same transaction.

Transient storage is accessed via two new EVM opcodes: TLOAD (0x5c) to read and TSTORE (0x5d) to write. It is a key-value store mapped per contract address, similar to storage slots. The data is private to the contract that writes it and is accessible across all internal calls, delegate calls, and static calls within the same transaction, but not to other externally called contracts.

A primary use case is implementing efficient reentrancy locks. Instead of using a persistent storage variable (which costs gas to set and clear), a contract can use a transient storage flag.

• Set flag: tstore(lock_slot, 1) at function entry.
• Check flag: tload(lock_slot) to prevent reentrancy.
• Automatic clear: The flag is auto-reset to 0 after the transaction, saving the ~5,000 gas for an sstore to clear it.

Transient storage is ideal for caching intermediate results within complex, multi-call transactions. For example, in a DeFi swap involving multiple pools:

• Calculate and store a best-path fee in transient storage during an initial assessment.
• Subsequent internal calls can tload this value without recalculating.
• The cached data is automatically discarded, avoiding the gas cost of writing and later clearing a persistent storage variable.

• vs. Memory (memory): Transient storage persists across internal calls; memory does not. It's for data shared between calls within a tx.
• vs. Storage (storage): Storage is persistent across transactions and costs ~20,000 gas for a cold sstore and ~5,000 gas to clear. Transient storage is temporary and has no cleanup cost.
• vs. Call Context: Data in transient storage is accessible in delegate calls, unlike call context variables like msg.sender.

The canonical use case for transient storage is implementing reentrancy guards. A contract can store a lock flag in a transient storage slot that is automatically cleared after the transaction ends, regardless of success or failure. This eliminates the gas cost of manually resetting the flag in storage and prevents leftover state that could block future calls.

• Gas Savings: No SSTORE needed to clear the 0->1->0 pattern.
• Safety: Flag is auto-reset, removing a potential bug vector.

Transient storage acts as a shared memory space for all contracts within a transaction's call chain. This is ideal for passing contextual data like:

• Original msg.sender through a series of proxy or wrapper contracts.
• Flash loan fees or specific parameters that only need to persist for the duration of the loan's execution.
• Oracle data that is fetched once and shared across multiple internal calls, avoiding repeated storage reads.

Automated Market Makers (AMMs) can use transient storage to track intermediate state during complex multi-pool swaps (e.g., Uniswap V3). Data like the remaining input amount or the current fee tier can be held in tstore and tload operations, which are significantly cheaper than their persistent storage counterparts. This reduces the overall gas overhead for users performing multi-hop trades.

Transient Storage sits between memory and storage in terms of persistence and cost:

• Memory (MLOAD/MSTORE): Cheapest, but scoped to a single contract call frame. Cannot be accessed by other contracts in the call chain.
• Transient Storage (TLOAD/TSTORE): Moderately priced, persists for the full transaction and is accessible across all call frames. Auto-cleared post-transaction.
• Persistent Storage (SLOAD/SSTORE): Most expensive, persists forever on-chain. Requires payment for state growth.

Maximal Extractable Value (MEV) searchers and arbitrage bots benefit from transient storage for organizing complex, multi-contract bundle transactions. It allows them to:

• Pass profitability calculations and routing paths between contracts.
• Set temporary permissions or flags for specific actions within the bundle.
• Reduce the gas footprint of their strategies, making marginally profitable opportunities viable.

The primary benefit of transient storage is gas efficiency. Unlike persistent storage (SSTORE), which incurs high costs for clearing slots, transient storage (TSTORE/TLOAD) is automatically cleared after a transaction, eliminating refund mechanisms and slashing gas costs for temporary data by up to 100x in specific patterns like reentrancy locks and function call contexts.

A canonical use case is implementing reentrancy protection. Instead of using a persistent storage flag (costly to reset), contracts can use a transient storage variable. This flag is automatically set to 1 on entry and cleared to 0 upon transaction completion, providing robust security with minimal gas overhead. This pattern is now recommended in the Solidity documentation.

Transient storage is ideal for passing data through a chain of internal calls or delegatecall proxies within a single transaction. It acts as a temporary, shared memory space that is:

• Scoped to the transaction and current contract execution context.
• Automatically cleaned, preventing storage bloat.
• Gas-cheap for intermediate state in complex operations like meta-transactions or flash loans.

EIP-1153 standardizes the TSTORE and TLOAD opcodes. Major networks have adopted it, creating a new standard for efficient contract design:

• Ethereum Mainnet: Activated in the Pectra upgrade.
• L2 Rollups: Widely available on Arbitrum, Optimism, Base, and zkSync Era.
• Other EVMs: Supported by Polygon PoS, BSC, and Avalanche C-Chain. This broad support ensures developer portability and consistent gas savings.

Transient storage (t_store) occupies a unique design space between memory and persistent storage:

• vs. Memory (memory): Transient storage is accessible across nested internal calls and delegatecall, while memory is call-context limited.
• vs. Storage (storage): Transient storage is wiped post-transaction with no gas cost for clearing, unlike persistent storage which requires an expensive SSTORE to zero out. It is a mutable, transaction-scoped data location.

Solidity ^0.8.24 introduced the t_store data location. Developers declare variables with t_store and use the TSTORE and TLOAD opcodes via assembly or future high-level syntax. Example use includes:

• Flash loan fee parameters passed to a callback.
• Auction bid data during a single transaction.
• Optimistic approval flags for batched operations. The feature requires compiler support and network activation.

Transient storage is a powerful tool for reentrancy guards. A contract can set a flag in transient storage at the start of a sensitive function and clear it at the end. Because the data is automatically cleared after the transaction, it is immune to cross-function reentrancy attacks that exploit leftover state in persistent storage. This simplifies the classic "checks-effects-interactions" pattern.

• Example: Setting tstore(REENTRANCY_GUARD_SLOT, 1) on entry and tstore(REENTRANCY_GUARD_SLOT, 0) on exit.

A key security benefit is preventing state pollution from failed sub-calls. Intermediate values passed between internal functions or to external contracts during a complex transaction can be stored transiently. If a sub-call reverts, the transient storage is still cleared, ensuring no garbage data persists in the contract's permanent state, which could be exploited in future transactions.

The security model is defined by the single-transaction lifecycle. Data is only accessible within the scope of the originating external call and its entire internal call chain. This makes it ideal for:

• Flash loan fee calculations that must be remembered across multiple operations but not persisted.
• Multi-step governance operations where votes or approvals are tallied and executed atomically.
• Delegatecall proxy contexts, where it avoids storage collisions between the proxy and implementation.

A critical security consideration is that transient storage must never be used for data that needs to persist beyond the current transaction. This includes:

• User balances or ownership records.
• Configuration settings or protocol parameters.
• Any data that must be queryable off-chain via events or static calls. Mistaking it for persistent storage is a severe vulnerability that will lead to permanent data loss.

Transient storage operations (TSTORE, TLOAD) have a fixed, low gas cost, unlike the high and variable costs of SSTORE. This changes the economic calculus for attack vectors. While it reduces the cost of secure patterns (like reentrancy guards), auditors must also consider that cheap writes could enable new forms of gas-griefing attacks within a transaction's call depth, though the impact is limited to that transaction.

Smart contract audits must now specifically review the use of tstore/tload. Key areas for auditors and developers to test:

• Correct Lifecycle Assumption: Verify data is not expected to persist.
• Slot Management: Ensure no unintended slot collisions between different internal functions.
• Integration with Upgrades: In upgradeable proxies, confirm transient storage slots are managed consistently across versions.
• Fuzzing Invariants: Include properties that state all transient storage slots must be zero at the start and end of a transaction in invariant tests.

In the EVM, storage is persistent, costly state written to the blockchain, while memory is a volatile, temporary byte-array scoped to a single contract call. Transient storage (TLOAD/TSTORE) is a third category: it is scoped to the entire transaction (like storage) but is automatically cleared after execution (like memory), making it ideal for reentrancy locks and gas-efficient temporary state.

A reentrancy guard is a pattern preventing a function from being called again before its first execution finishes. Traditionally, this uses a persistent storage boolean flag (costly). With transient storage, a guard can be set using TSTORE at the start of a call and checked with TLOAD, providing the same security guarantee without writing to permanent storage, saving significant gas.

Call context refers to the execution environment of an EVM call, including variables like msg.sender and msg.value. Transient storage is unique because it is shared across the entire call context of a transaction. This means a value written by the original msg.sender in an external call can be read by a subsequent internal call from a different contract, enabling new cross-contract communication patterns within a single transaction.

Transient storage is a major gas optimization tool. Key savings come from:

• No Refunds: Unlike SSTORE clearing, there is no gas refund mechanism, simplifying gas accounting.
• Fixed Low Cost: TSTORE and TLOAD have minimal, predictable gas costs.
• No State Bloat: Since data is ephemeral, it does not contribute to long-term blockchain state growth, reducing network load.

While often used interchangeably, ephemeral storage is a broader term. In blockchain contexts:

• Transient Storage (EIP-1153): A specific EVM feature with transaction scope.
• Memory: Ephemeral but only call-scoped.
• Calldata: Immutable, transaction-scoped input data.
• Stack: EVM's ultra-fast, volatile LIFO data structure. Transient storage fills a specific niche between persistent storage and call-scoped memory.