Transient Storage (EIP-1153)

What Is Transient Storage?

Transient storage is a third category of data storage in the Ethereum Virtual Machine (EVM), introduced by EIP-1153. Before this proposal, smart contracts had two storage options: persistent storage (SSTORE/SLOAD), which writes data to the blockchain permanently and costs up to 20,000 gas, and memory, which is cheap but only exists within a single function call. Transient storage fills the gap between them: it persists across all internal calls within a transaction, then is automatically cleared when the transaction ends.

The proposal was authored by Alexey Akhunov and Moody Salem, with Salem bringing direct experience from Uniswap's need for cheaper intra-transaction bookkeeping. EIP-1153 was included in Ethereum's Dencun hard fork, which activated on mainnet on March 13, 2024, at epoch 269568. The Dencun upgrade also introduced blob transactions (EIP-4844) for rollup data availability and the MCOPY opcode (EIP-5656) for cheaper memory copying.

How It Works

EIP-1153 adds two new opcodes to the EVM instruction set:

• TSTORE (opcode 0x5D): writes a 32-byte value to a transient storage slot, identified by a 32-byte key. Costs 100 gas.
• TLOAD (opcode 0x5C): reads a 32-byte value from a transient storage slot. Also costs 100 gas.

These opcodes use the same key-value addressing model as SSTORE and SLOAD. Each contract has its own isolated transient storage space, just as it has its own persistent storage. The critical difference is lifecycle: transient storage exists only for the duration of the transaction. Once the transaction completes (whether it succeeds or reverts at the top level), all transient storage slots are wiped.

Gas Comparison

The cost savings over persistent storage are substantial. The following table compares the gas costs for common storage patterns:

The write-read-clear pattern is where transient storage shines most. A reentrancy guard using persistent storage pays roughly 25,000 gas for the full cycle (cold write, warm read, reset). With transient storage, the same pattern costs just 200 gas (one TSTORE, one TLOAD) because no reset is needed.

Revert Behavior

Transient storage interacts with reverts in a specific way: if a sub-call reverts, its transient storage changes are rolled back, just like persistent storage changes. This means transient storage follows the same atomicity guarantees within nested call frames. However, if the top-level transaction succeeds, all transient storage is still discarded at the end.

One design constraint follows from this: TSTORE is not permitted inside a STATICCALL (which prohibits state modifications). TLOAD, however, is allowed in static contexts because reading transient storage does not modify state.

Solidity Example

In Solidity, transient storage can be accessed through inline assembly or, in newer compiler versions, with the transient storage location keyword:

// Reentrancy guard using transient storage (inline assembly)
contract TransientReentrancyGuard {
    bytes32 constant LOCK_SLOT = keccak256("REENTRANCY_LOCK");

    modifier nonReentrant() {
        assembly {
            if tload(LOCK_SLOT) { revert(0, 0) }
            tstore(LOCK_SLOT, 1)
        }
        _;
        assembly {
            tstore(LOCK_SLOT, 0)
        }
    }
}

This replaces the traditional OpenZeppelin ReentrancyGuard pattern, which uses SSTORE to toggle a lock variable between 1 and 2, paying thousands of gas per invocation.

Use Cases

Flash Accounting in Uniswap v4

The most prominent use of transient storage is flash accounting in Uniswap v4. Instead of transferring tokens at every hop in a multi-hop swap, the protocol records intermediate balance changes (deltas) in transient storage. Only the final net balances are settled with actual token transfers at the end of the transaction.

For example, a three-hop swap (Token A to B, B to C, C to D) under Uniswap v3 required six token transfers: two per hop. Under v4 with flash accounting, the same swap requires only two transfers: one for the input token (A) and one for the output token (D). The intermediate B and C balances are tracked in transient storage and netted out, since they cancel each other within the same transaction. For a deeper look at how Uniswap v4 hooks and flash accounting work together, see the Uniswap v4 hooks deep dive.

Reentrancy Guards

Reentrancy attacks remain one of the most common smart contract vulnerabilities. The standard defense is a mutex lock that prevents recursive calls. Before EIP-1153, this lock required writing to persistent storage on every protected function call, making it a significant gas overhead for frequently called functions like DEX swaps.

Transient storage makes reentrancy guards essentially free. The lock value only needs to exist for the duration of the transaction, which is exactly what transient storage provides. This removes the economic disincentive to add reentrancy protection to gas-sensitive code paths.

Callback Verification

Many DeFi protocols use a callback pattern where Contract A calls Contract B, which then calls back into Contract A. The callback function needs to verify that it was legitimately triggered by Contract A's own operation, not by an external attacker. Transient storage provides a cheap way to set a flag before the external call and check it in the callback, without paying for persistent storage.

ERC-20 Approval Optimization

Patterns that need temporary token approvals (approve, transfer, then revoke) can use transient storage to track approval state within a single transaction, avoiding the gas cost of writing and clearing an allowance in persistent storage.

Risks and Considerations

Slot Reuse Vulnerabilities

The most significant real-world risk emerged in March 2025, when the DeFi protocol SIR.trading lost approximately $355,000 due to a transient storage vulnerability. The contract stored a Uniswap V3 pool address in a transient slot for callback verification, then later overwrote that same slot with a swap amount. An attacker exploited this reuse: they deployed a contract at a brute-forced address that could pass the callback verification check, draining the vault.

The lesson is that transient storage slots persist across all internal calls within a transaction, not just the immediate call frame. If a contract writes to a transient slot in one code path and reads it in another, the values can collide. Developers should use purpose-specific, namespaced slot keys (such as hashing a unique identifier per use case) and avoid reusing slots for different purposes within the same contract.

Not Equivalent to Memory

Developers sometimes treat transient storage as "cheap memory," but the two have fundamentally different scoping. Memory is local to a single call frame and cannot be read by sub-calls. Transient storage is visible across all call frames within a transaction, which is both its power (enabling cross-contract communication) and its risk (enabling unintended data sharing).

STATICCALL Restrictions

Because TSTORE modifies state (even if only transiently), it reverts inside a STATICCALL. Contracts that rely on view functions calling other contracts cannot use TSTORE in those call paths. TLOAD is permitted in static contexts, so reading transient data from view functions works fine.

No Cross-Transaction Persistence

Transient storage cannot replace persistent storage for any data that must survive beyond a single transaction. Configuration values, balances, ownership records, and any state that needs to be queried by later transactions must still use SSTORE. Transient storage is strictly for intra-transaction bookkeeping.

Proposed Gas Reduction

A draft proposal (EIP-7971) suggests lowering transient storage costs further, to 5 gas for TLOAD and 12 gas for TSTORE, with a per-transaction cap of 131,072 transient slots to prevent denial-of-service attacks. This proposal has not been finalized, but it signals ongoing interest in making transient storage even cheaper for high-frequency patterns like flash accounting.

Transient Storage and Layer 2 Networks

EIP-1153 applies to any EVM-compatible chain, not just Ethereum mainnet. Layer 2 rollups and sidechains that implement the Dencun opcode set inherit transient storage support. BNB Chain adopted EIP-1153 through BEP-343, and most EVM-compatible rollups include it as part of their Dencun-equivalent upgrades.

For gas-sensitive applications on Layer 2 networks, where base fees are already low, transient storage still offers value by reducing state bloat. Even when gas is cheap, avoiding unnecessary persistent storage writes keeps the chain's state tree smaller and improves node performance over time.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.