ERC-3664

ERC-3664, also known as the CCIP Read standard, is an Ethereum Request for Comments that defines a protocol for storing and retrieving NFT metadata and other data in a hybrid on-chain/off-chain manner. Its primary innovation is the IERC3664 interface, which allows smart contracts to store a minimal on-chain reference—such as a URI or a commitment hash—that points to more extensive data stored off-chain. This design provides the immutable on-chain proof of an NFT's properties while enabling flexible, cost-effective storage of complex data like high-resolution images, videos, or dynamic attributes, solving the gas cost and blockchain bloat problems of storing all data directly on-chain.

The standard operates through a system of modular attestations. Instead of a single metadata URI, an NFT contract implementing ERC-3664 can manage multiple data attributes (e.g., image, strength, background), each with its own off-chain source and on-chain identifier. A core mechanism is the resolve function, which a client (like a wallet or marketplace) calls to fetch the data. This function reads the on-chain pointer and then performs a CCIP Read operation: it calls a designated off-chain gateway (like an HTTP server or IPFS node), which returns the verified data. This process allows for gas-efficient updates to NFT traits without modifying the core contract, enabling dynamic and evolving NFTs.

Key technical components include the TextResolver and AddrResolver interfaces for resolving text-based data (URIs) and Ethereum addresses, respectively. A major advantage is data integrity: the off-chain response must include a proof, often a cryptographic signature from a trusted attester, which the client verifies against the on-chain commitment. This prevents tampering and ensures the off-chain data is authoritative. Furthermore, ERC-3664 supports composability, allowing different attributes to be sourced from different providers, fostering a decentralized ecosystem of specialized data attestation services.

Practically, ERC-3664 is foundational for Soulbound Tokens (SBTs), verifiable credentials, and complex gaming or metaverse assets where properties change frequently. For example, a game character NFT could have a static on-chain token ID, while its evolving level, equipment, and appearance are stored as efficiently updatable off-chain attributes resolved via ERC-3664. It is a critical piece of infrastructure for the modular blockchain stack, separating the consensus and execution layer (Ethereum) from the data availability and retrieval layer, paving the way for more scalable and feature-rich NFT applications.

The term ERC-3664 follows the established Ethereum Improvement Proposal (EIP) numbering convention, where 'ERC' stands for Ethereum Request for Comments and '3664' is its unique identifier assigned by the EIP editors. This nomenclature places it within the broader family of Ethereum standards, specifically those focused on token interfaces (ERC-20, ERC-721) and application-layer protocols. The number itself is sequential and carries no inherent technical meaning, serving primarily as a unique reference.

The proposal was authored by Nick Johnson and Qiao Wang and was formally introduced as EIP-3664 in April 2021. Its origin lies in addressing a critical limitation of the Ethereum Virtual Machine (EVM): the high cost and technical complexity of storing and retrieving large or complex data on-chain. The standard was conceived to enable gas-efficient and flexible data retrieval without requiring changes to the core protocol, building upon concepts from earlier standards like ERC-1155 and the idea of composable attributes.

The core innovation, CCIP Read, is etymologically derived from Cross-Chain Interoperability Protocol Read, though its application within ERC-3664 is generalized for any off-chain data source. This mechanism allows a smart contract to defer data resolution to an off-chain gateway, responding to queries with a payload that instructs the client (e.g., a wallet or dApp interface) where to fetch the real data. This decouples data storage from data availability, a pattern inspired by the need for scalability and richer metadata in applications like advanced NFTs and decentralized identity.

The development of ERC-3664 was directly influenced by the growing demands of the Non-Fungible Token (NFT) ecosystem for dynamic, upgradable, and gas-efficient metadata. Prior to its introduction, projects had to choose between expensive on-chain storage or fully centralized off-chain solutions. ERC-3664 provided a standardized, cryptographically verifiable middle path, enabling traits, images, and other attributes to be stored on decentralized networks like IPFS or Arweave while maintaining a lightweight on-chain footprint.

In practice, ERC-3664's origin as a generic data retrieval primitive has led to its adoption beyond its initial NFT use case. It serves as a foundational layer for L2 resolution protocols, decentralized domain name systems (like ENS's off-chain metadata), and any application requiring trust-minimized access to external data. Its design reflects a broader trend in Ethereum's evolution: creating standards that extend the chain's capabilities through secure off-chain computation and verification, rather than through constant and costly on-chain expansion.

ERC-3664 defines a standardized interface for off-chain lookup, allowing a smart contract to request data from an external source. When a contract needs information not stored on-chain, it can revert the transaction with a special error containing a gateway URL and call data. This triggers a client, like a wallet or a node, to perform a CCIP Read (Cross-Chain Interoperability Protocol Read) by sending an HTTP POST request to the specified gateway. The gateway, which acts as a stateless data provider, returns the required data, which the client then submits in a new transaction to complete the original contract call. This mechanism decouples data retrieval from on-chain execution.

The core innovation is the secure and verifiable nature of the data fetch. The gateway's response must include a cryptographic proof, such as a Merkle proof, which the receiving smart contract can validate on-chain. This ensures the data's integrity and authenticity before it is used. The standard supports multiple proof types and data formats, making it flexible for various use cases like fetching verifiable random numbers (VRF), decentralized identity (DID) attestations, or price feeds. By placing the burden of the HTTP call on the client, it eliminates gas costs for data retrieval and avoids the single point of failure associated with traditional oracle networks.

A primary application of ERC-3664 is enhancing the Ethereum Name Service (ENS). It allows ENS resolvers to store only a lightweight hash on-chain while delegating the task of fetching the actual record (like an IPFS hash or cryptocurrency address) to an off-chain gateway. This drastically reduces gas costs for record updates. Developers implement the standard by having their contracts inherit from or interface with the IERC3664 functions, primarily resolve and callback. Prominent projects utilizing this pattern include ENS's off-chain resolvers and various Layer 2 scaling solutions that need to bridge data from their own networks back to Ethereum mainnet.