SSTORE2 / SSTORE3

SSTORE2 (EIP-3540) is a smart contract library that allows developers to store arbitrary data on-chain in a highly gas-efficient manner. Instead of using the standard SSTORE opcode to write data directly to a contract's storage slots, SSTORE2 stores the data as a single, immutable blob and returns a pointer to its location. This pointer is the keccak256 hash of the data, which can be used to retrieve it later. This method is particularly efficient for storing data that is written once and read many times, as the write cost is amortized over all future reads, which become significantly cheaper than reading from traditional contract storage.

The primary use case for SSTORE2 is the on-chain storage of contract creation code or initialization bytecode. This enables the deployment of contracts using the CREATE2 opcode with deterministic addresses, where the runtime bytecode is stored separately via SSTORE2. It is also used for storing large, static datasets like NFT collection metadata, generative art scripts, or extensive configuration parameters. The pattern decouples expensive one-time storage costs from the contract's runtime logic, leading to substantial long-term gas savings for applications that frequently access this immutable data.

SSTORE3 (EIP-7496) is a proposed successor and extension of the SSTORE2 concept, aiming to further reduce gas costs and increase flexibility. While SSTORE2 stores data in the storage of a singleton factory contract, SSTORE3 proposes storing data directly within the contract code section itself, accessed via a new DATAHASH opcode. This approach leverages the fact that reading from code is cheaper than reading from storage. SSTORE3 would make the retrieval of stored data even more gas-efficient and could enable new patterns for on-chain libraries and modular smart contract systems by treating contract code as a generic data store.

The SSTORE opcode, short for "Storage Store", is a fundamental EVM instruction that writes a 256-bit word to a contract's persistent key-value storage at a specified slot. It is notoriously gas-expensive, especially for initial writes (SSTORE from zero to non-zero) and for storing large amounts of data. The high cost stems from the requirement that every node in the Ethereum network must permanently replicate this data. The search for more economical storage methods directly led to the conceptual development of SSTORE2 and SSTORE3 as design patterns, not new opcodes.

SSTORE2 was pioneered as a community-driven standard to drastically reduce the cost of storing large, immutable data blobs (like contract bytecode or NFT metadata). Instead of using SSTORE repeatedly for each byte, SSTORE2 works by pushing the data into a separate contract creation transaction. The data becomes the runtime bytecode of a new, minimal contract. The original calling contract then stores only a pointer—the address of this newly created data contract—using a single, costly SSTORE. Subsequent reads are performed using the EXTCODECOPY opcode to retrieve the data from the code of the data contract, which is much cheaper than reading from storage.

SSTORE3, a further refinement, optimizes the pointer itself. While SSTORE2 uses a full 20-byte Ethereum address as a pointer, SSTORE3 leverages the fact that contract addresses are deterministically derived from the sender and a nonce. A common SSTORE3 implementation involves storing only a salt or a nonce (a much smaller 32-byte value) used in a CREATE2 operation. The actual data contract address can be recomputed on-chain using this salt and the factory contract's address. This can reduce the pointer storage cost by nearly 50%, as storing 32 bytes once is cheaper than storing 20 bytes.

The evolution from SSTORE to SSTORE2 and SSTORE3 highlights a core principle in blockchain optimization: trade computation for storage. The patterns accept the one-time cost of contract creation and the computational overhead of EXTCODECOPY or CREATE2 address derivation to achieve massive, recurring savings on storage gas. This makes them ideal for immutable data such as NFT art, document hashes, or configuration data that must be referenced frequently but never altered.

These patterns are not without trade-offs. Data stored via SSTORE2/SSTORE3 becomes truly immutable and cannot be altered by the parent contract, as it resides as code in a separate contract. Furthermore, access is slightly more complex and requires explicit logic for reading. Despite this, their adoption in gas-sensitive applications like on-chain generative art and efficient data layers demonstrates their practical utility, standing as a testament to developer ingenuity in working within the constraints of the EVM's economic model.

SSTORE2 (EIP-3448) is a meta-proposal that introduces a pattern for storing immutable data by deploying a contract whose creation code returns the data. Instead of writing data directly to storage, a contract is created with the data embedded in its initcode. The contract's address becomes a deterministic pointer to the data, which can be retrieved using the EXTCODECOPY opcode. This method is significantly cheaper for one-time storage as it avoids the high gas costs of SSTORE and reduces permanent state bloat, as contract code is stored differently in the Ethereum state trie.

SSTORE3 (EIP-7490) is a direct successor and improvement over SSTORE2. It proposes a new precompiled contract, DATASTORE, which provides a standardized, singleton interface for storing and retrieving immutable data blobs. Users call the precompile with their data, which returns a unique content identifier (a bytes32 pointer). This pointer can later be used with the same precompile to retrieve the original data. SSTORE3 offers several advantages over its predecessor: a unified contract address, reduced deployment overhead, and a simpler, more gas-efficient API for both storage and retrieval.

The core innovation of both standards is the shift from mutable contract storage to immutable contract code or a dedicated precompile for data. While SSTORE opcode writes are expensive because they modify the global state, storing data as code or via a precompile is a one-time cost with minimal ongoing state impact. This makes SSTORE2/SSTORE3 ideal for storing large, static assets like NFT metadata, contract configuration parameters, or script code for on-chain libraries, where the data does not need to be updated after creation.

From a developer's perspective, using SSTORE3 involves interacting with the precompile at a known address. To store data, you call DATASTORE.store(bytes memory data) and receive a bytes32 pointer. To read it, you call DATASTORE.read(bytes32 pointer). This abstracts away the complexity of contract creation and code hashing present in SSTORE2. The deterministic nature of the pointer—derived from the data's hash—ensures that the same data will always produce the same pointer, enabling efficient deduplication and content-addressable storage on-chain.

These mechanisms address critical pain points in Ethereum's economic model. By providing a low-cost alternative for immutable data, they enable new use cases that were previously prohibitively expensive, such as fully on-chain generative art, extensive on-chain documentation, or deploying large libraries of reusable code. As EIPs, their adoption requires network upgrades, but they represent a fundamental evolution in how developers conceptualize and pay for persistent data storage within the Ethereum ecosystem.

The core conceptual flow begins with a user or contract preparing a piece of immutable data, such as a large dataset or a contract's bytecode. In a traditional SSTORE operation, this data would be written directly to the contract's storage slots, incurring high gas costs proportional to the data size and making it permanently mutable. The SSTORE2 and SSTORE3 patterns fundamentally alter this flow by separating the data from the contract's primary storage logic.

Instead of storing the data itself, the flow involves first computing a cryptographic commitment to the data. For SSTORE2, this is the bytes32 keccak256 hash of the data. For SSTORE3, it is a contract address derived deterministically from a salt and the data's hash, which will later house the data. This commitment (a hash or a future address) is what is stored in the calling contract's storage using a single, relatively cheap SSTORE operation. The actual raw data is then stored elsewhere in a finalized transaction.

The retrieval flow reverses this process. To access the data, the contract reads the stored commitment. In SSTORE2, it uses this hash to locate the data within the historical transaction calldata via the pointer contract. In SSTORE3, it uses the pre-computed address to create a static call to the newly deployed data contract, which returns the data from its immutable constructor argument. This decouples the cost of frequent data reads (a cheap SLOAD and static call) from the expensive one-time cost of data writing.

A key conceptual difference in the flow is gas cost timing. With traditional storage, high costs are paid upfront and for every subsequent write. With SSTORE2/SSTORE3, the majority of the gas cost is paid during the initial data creation transaction (for the calldata or contract creation). The "owner" contract then holds only a minimal, persistent reference, optimizing the system for data that is written once and read many times, which is a common pattern for metadata, art assets, or library code.