Solc Transient Storage Helper Collision (2026-02) Remediation
Overview
Related Detector: Solc Transient Storage Helper Collision (2026-02)
On the IR pipeline, Solidity 0.8.28 through 0.8.33 named the zeroing helper for delete by value type only, ignoring whether the slot was persistent or transient. Deduplication by name then let one helper serve both, so delete on a transient variable could emit an sstore and corrupt persistent storage, while delete on a persistent variable could emit a tstore and leave state untouched. This is a compiler bug in the EIP-1153 transient-storage adoption window; the remediation is to rebuild with a fixed compiler.
Recommended Fix
// Affected: solc 0.8.28–0.8.33 compiled via the IR pipeline (--via-ir),
// in contracts that use both `transient` and persistent state and `delete` them.
// Fixed in: solc 0.8.34.
pragma solidity ^0.8.34; // or laterSteps:
- Recompile with 0.8.34 or later (via-IR).
- Redeploy any affected contract that uses transient storage alongside persistent storage.
- Audit the on-chain state of already-deployed affected contracts for corruption before relying on it — a wrong
sstore/tstoremay have already mutated persistent slots.
Common Mistakes
- Assuming only transient state is at risk; the collision is bidirectional and can corrupt persistent storage.
- Rebuilding with the legacy pipeline and concluding the contract is safe without confirming the deployed bytecode came from a fixed compiler.
- Overlooking that state written by an affected deployment may already be wrong, independent of the recompile.