{"id":"EIP-1153","name":"Transient Storage Opcodes","status":"Final","chain":"both","category":{"id":"defi","name":"DeFi Patterns","description":"Vaults, bonds, and financial primitives"},"journeyStages":[{"id":"gas","name":"Gas & Fees","description":"Paying for transactions"}],"uxImpact":"EIP-1153 introduced transient storage: data that exists only for a transaction and is automatically cleared afterward. TSTORE/TLOAD can be cheaper than persistent storage for temporary values such as reentrancy locks, but any user-level gas savings depend on the surrounding implementation and current transaction estimate.","officialUrl":"https://eips.ethereum.org/EIPS/eip-1153","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-1153","summary":"EIP-1153 introduced transient storage: data that exists only for a transaction and is automatically cleared afterward. TSTORE/TLOAD can be cheaper than persistent storage for temporary values such as reentrancy locks, but any user-level gas savings depend on the surrounding implementation and current transaction estimate.","applicability":{"whenToUse":["Your product addresses: temporary data was expensive to store.","Your product addresses: callback patterns wasted gas.","The flow should deliver: measured gas estimates explain any transient-storage benefit without promising a fixed saving.","Fee screens need estimates, speed options, and plain-language breakdowns."],"whenToAvoid":["The product has no transaction fee estimate or user-facing execution flow.","The deployed implementation does not use transient storage in the measured path.","No baseline exists for a defensible before/after gas comparison.","No token balances, swaps, lending, or yield flows appear in the product."]},"designerTakeaways":["You can show measured transaction savings when the deployed implementation uses transient storage.","Design the flow to support transient storage auto-clears, no cleanup cost.","Design the flow to support pass data between calls cheaply via transient storage."],"problemsSolved":[{"problem":"Temporary data was expensive to store","oldWay":"Reentrancy locks cost 20,000 gas to set, 5,000 to clear","newWay":"TSTORE/TLOAD have protocol-defined opcode costs; total savings depend on the surrounding implementation","impact":"high"},{"problem":"Callback patterns wasted gas","oldWay":"Flash loans and callbacks stored then deleted state","newWay":"Transient storage auto-clears, no cleanup cost","impact":"high"},{"problem":"Complex transactions were expensive","oldWay":"Multi-step DeFi needed multiple storage writes","newWay":"Pass data between calls cheaply via transient storage","impact":"medium"},{"problem":"Reentrancy protection added significant gas overhead","oldWay":"Every protected function paid storage costs","newWay":"Lower-cost reentrancy guards when the implementation and gas estimate support it","impact":"medium"}],"uxPatterns":[{"name":"Gas Savings Display","description":"Show users when transient storage reduces their costs","userFlow":["User sets up flash loan strategy","Gas estimated with transient storage optimizations","Savings shown only from a measured or simulated legacy comparison","User sees net profit including optimized gas","Execute with confidence in lower costs"]},{"name":"DeFi Action Breakdown","description":"Show gas breakdown including transient storage benefits","userFlow":["User views transaction details","Gas breakdown shows individual costs","Transient storage optimizations highlighted","Total cost displayed","User understands where gas goes"]},{"name":"Protocol Efficiency Badge","description":"Show which protocols use gas-efficient patterns","userFlow":["User comparing DEX options","Optimized protocols marked","Gas costs clearly compared","User can factor efficiency into choice"]}],"uiComponents":[{"name":"GasSavingsBadge","description":"Shows measured or simulated transaction savings when the surrounding implementation uses EIP-1153","states":["optimized","standard","unknown"],"props":["savingsAmount","savingsPercent","showTooltip"]},{"name":"GasBreakdownList","description":"Itemized gas costs with optimization highlighting","states":["loading","loaded","error"],"props":["items[]","total","optimizations[]"]},{"name":"ProtocolEfficiencyBadge","description":"Indicates a measured or documented gas optimization that may include EIP-1153","states":["optimized","standard"],"props":["optimizations[]","tooltip"]}],"antiPatterns":[{"pattern":"Hiding gas optimization benefits","why":"Users don't know they're getting better deal","instead":"Show \"Optimized\" badge and savings amount","severity":"medium"},{"pattern":"Not comparing to legacy costs","why":"Users can't appreciate the improvement","instead":"Show a measured \"Saved $X vs baseline\" value only when the comparison is reproducible","severity":"low"},{"pattern":"Over-explaining technical details","why":"Users don't need to know about TSTORE/TLOAD opcodes","instead":"Just show \"Gas Optimized\" or \"Efficient\" badge","severity":"low"}],"relatedStandards":[{"id":"ERC-3156","relationship":"Flash loans benefit significantly from transient storage for callbacks"},{"id":"EIP-1559","relationship":"Base fee accounting helps applications measure any transient-storage cost change"},{"id":"ERC-4337","relationship":"Account abstraction operations can use transient storage for validation data"}],"specConstraints":[{"id":"transient-memory-lifetime","constraint":"Transient storage is lifecycle-wise closer to memory than persistent storage and should be treated as transaction-scoped temporary state.","appliesTo":"account-implementation","normativity":"rationale","specQuote":"transient storage is more akin to memory than storage in lifecycle.","specSection":"Rationale","specUrl":"https://eips.ethereum.org/EIPS/eip-1153#rationale","designImplication":"Do not present transient values as durable balances, preferences, or records; keep user-facing state tied to the transaction and implementation that actually persists it."},{"id":"activation-availability","constraint":"The network must activate the EIP's hard-fork changes before TSTORE and TLOAD can be relied on.","appliesTo":"infrastructure","normativity":"backwards-compatibility","specQuote":"This EIP requires a hard fork to implement.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-1153#backwards-compatibility","designImplication":"Gate feature claims and gas comparisons on the target network's activation and client support; show a fallback or unavailable state when transient storage is not live."},{"id":"transient-revert-semantics","constraint":"Within a transaction, transient storage must preserve storage-like revert behavior so earlier transient state can be restored.","appliesTo":"account-implementation","normativity":"rationale","specQuote":"the transient storage must behave almost identically to storage within the context of a single transaction with regards to revert behavior","specSection":"Reference Implementation","specUrl":"https://eips.ethereum.org/EIPS/eip-1153#reference-implementation","designImplication":"Model failed calls and nested frames as state-reverting outcomes in previews and account implementations; do not show a transient update as committed when its transaction frame reverted."},{"id":"transient-memory-budget","constraint":"TSTORE creates a linear-cost way to allocate memory on a node, so implementations must account for its bounded transaction resource use.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"TSTORE presents a new way to allocate memory on a node with linear cost.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-1153#security-considerations","designImplication":"Keep resource and fee estimates grounded in the actual transaction and node limits; do not describe transient storage as free or unbounded memory."},{"id":"transient-reentrancy-lifetime","constraint":"Transient storage is not discarded when a call returns or reverts, unlike memory, and can create unexpected re-entrancy behavior within one transaction.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"Smart contract developers may also be tempted to use transient storage as an alternative to in-memory mappings. They should be aware that transient storage is not discarded when a call returns or reverts, as is memory, and should prefer memory for these use cases so as not to create unexpected behavior on reentrancy in the same transaction.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-1153#security-considerations","designImplication":"Show re-entrancy-sensitive operations as transaction-scoped and test nested calls; do not claim that a call return or revert clears transient state the way memory is cleared."},{"id":"transient-slot-clearing","constraint":"Account implementations SHOULD understand transient-storage lifetime and leave nonzero slots only when future same-transaction calls intentionally rely on them.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"Smart contract developers should understand the lifetime of transient storage variables before use. Because transient storage is automatically cleared at the end of the transaction, smart contract developers may be tempted to avoid clearing slots as part of a call in order to save gas. However, this could prevent further interactions with the contract in the same transaction (e.g. in the case of re-entrancy locks) or cause other bugs, so smart contract developers should be careful to _only_ leave transient storage slots with nonzero values when those slots are intended to be used by future calls within the same transaction. Otherwise, these opcodes behave exactly the same as `SSTORE` and `SLOAD`, so all the usual security considerations apply especially in regard to reentrancy risk.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-1153#security-considerations","designImplication":"For flows that rely on transient locks or other same-transaction state, model cleanup and nested-call behavior explicitly; do not treat automatic end-of-transaction clearing as a substitute for deliberate slot lifecycle handling."}],"lastUpdated":"2026-09-18","sources":[{"label":"EIP-1153 official specification","url":"https://eips.ethereum.org/EIPS/eip-1153","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-1153","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-1153","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-1153","markdown":"https://www.eipsfordesigners.com/standards/EIP-1153/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-1153/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-1153","official":"https://eips.ethereum.org/EIPS/eip-1153","discussion":"https://ethereum-magicians.org/search?q=EIP-1153"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}