EIP-1153 Explained: Transient Storage Opcodes in Ethereum
Temporary storage inside Ethereum transactions
Ethereum is constantly evolving to make smart contracts faster, cheaper, and easier to build. One of the most exciting improvements in recent years is EIP-1153, which introduces something called transient storage.
In this article, we’ll break down EIP-1153 in simple terms:
What problem does it solve
How transient storage works
Why it matters for developers
Real-world use cases in DeFi
Let’s dive in.
What is EIP-1153?
EIP-1153 is an Ethereum Improvement Proposal that introduces two new EVM opcodes:
TLOAD (0x5c)
TSTORE (0x5d)
These opcodes allow smart contracts to store and retrieve temporary data during a transaction.
The key idea is:
Transient storage behaves like normal storage, but it is automatically erased after the transaction ends.
So instead of writing data permanently to the blockchain, contracts can store values temporarily for just one transaction.
Why Do We Need Transient Storage?
Transactions often need temporary data that lasts longer than one function call, but does not need to be saved permanently.
Example:
Reentrancy locks
Flash loan bookkeeping
Temporary approvals
Proxy metadata
Today, developers typically use persistent storage for these temporary needs.
That’s where the problem begins.
The Core Problem with Storage Today
Ethereum contracts currently use:
SSTORE→ write to storageSLOAD→ read from storage
But storage comes with major downsides:
1. Storage is Expensive
Writing to permanent storage costs a lot of gas.
Even though Ethereum offers gas refunds, EIP-3529 capped refunds to only 20%, making temporary storage patterns even less efficient.
So developers pay high gas costs even when the data is only needed for a short period.
2. Passing Data Through CALL Frames is Unsafe
Ethereum transactions can involve many nested calls:
Contract A calls Contract B
Contract B calls Contract C
Contract A may even be re-entered again
If an untrusted contract sits in the middle, passing information through call inputs/outputs becomes risky.
Developers use costly and awkward fixes
Because there’s no dedicated temporary storage, developers end up using expensive and awkward patterns for simple logic.
What is Transient Storage?
Transient storage is a new storage area that:
Works like storage inside a transaction
Is shared across all calls within the same contract
Disappears completely after the transaction finishes
Think of it as:
Storage with the lifetime of a transaction.
The New Opcodes: TLOAD and TSTORE
EIP-1153 introduces:
TSTORE
Stores a 32-byte value temporarily:
TSTORE(key, value)
TLOAD
Loads a value back:
value = TLOAD(key)
Key rules:
Data is not persisted on-chain
Data is cleared automatically at the transaction end
Only the owning contract can access its transient storage
Gas Cost Benefits
Transient storage is much cheaper:
| Operation | Gas Cost |
|---|---|
| TLOAD | ~100 gas |
| TSTORE | ~100 gas |
This is comparable to warm storage operations, but without the overhead of:
disk writes
refund accounting
permanent state growth
Revert Behavior (Important Detail)
Transient storage behaves like normal storage when it comes to reverts:
- If a call frame reverts, all transient writes inside it are undone.
So developers get predictable behavior.
Also:
TSTOREis forbidden insideSTATICCALLTLOADis allowed
Real-World Use Cases
EIP-1153 unlocks many powerful patterns.
1. Cheap Reentrancy Locks
Reentrancy guards are common security tools, but expensive with SSTORE.
Transient storage makes them cheaper and automatically clears them.
2. Flash Loan Accounting
Flash loans require tracking balances only within one transaction.
Transient storage is perfect for this kind of short-lived bookkeeping.
3. Single-Transaction ERC-20 Approvals
Instead of approving a spender forever, contracts can implement:
- Temporary approvals are valid for only one transaction
This improves safety and reduces the attack surface.
4. Proxy Metadata Passing
Proxies can store temporary call metadata without bloating calldata or permanent storage.
Security Considerations
Transient storage is powerful, but developers must understand its lifetime:
It lasts across calls within the same transaction
It is cleared only at transaction end
Therefore, if a contract sets a lock but fails to clear it, it may remain locked during subsequent calls within the same transaction.
Best practice:
Use memory for local variables
Use transient storage only for cross-call temporary state
Why Not Just Use Memory Instead?
Memory is cheaper, but it resets after every call.
Transient storage survives across multiple calls in the same transaction, which is essential for:
mappings
approvals
multi-call DeFi patterns
So the two serve different purposes.
Conclusion
EIP-1153 is a major improvement for Ethereum smart contracts.
It introduces transaction-scoped storage that is:
cheaper
temporary
safer for inter-call communication
useful for DeFi patterns
With transient storage, developers can build smarter, cleaner, and more gas-efficient applications without bloating Ethereum’s permanent state.
Final Thoughts
EIP-1153 is one of those upgrades that might seem small (just two opcodes), but it unlocks huge improvements in smart contract design.
As Ethereum scales, features like this will help make contracts more efficient and easier to secure.
