EIP-1153 Transient Storage Security Traps: How a Gas Optimization Killed SIR.trading and What Your Reentrancy Guard Is Missing
Transient storage was supposed to be simple: cheap scratch space that vanishes after each transaction. EIP-1153 introduced TSTORE and TLOAD opcodes in Ethereum's Dencun upgrade, and developers imme...

Source: DEV Community
Transient storage was supposed to be simple: cheap scratch space that vanishes after each transaction. EIP-1153 introduced TSTORE and TLOAD opcodes in Ethereum's Dencun upgrade, and developers immediately started replacing expensive SSTORE/SLOAD patterns with their gas-efficient counterparts. Uniswap V4 built its entire hook architecture around it. OpenZeppelin shipped transient reentrancy guards. Everything looked great. Then SIR.trading lost $355,000 in March 2025 because someone forgot to clear a transient storage slot. This article dissects the security model of transient storage — not the happy path, but the edge cases that break your contracts when you assume TSTORE is just a cheaper SSTORE. The Mental Model That Gets Developers Killed Here's the dangerous assumption: "Transient storage clears automatically at the end of every transaction, so I don't need to manage its lifecycle." This is technically true and practically lethal. The problem isn't end-of-transaction behavior — it'