ERC-3668, also called CCIP-Read or Durin, is an Ethereum standard that allows smart contracts to revert with an offchain data request rather than an error. The client catches the revert, fetches data from the URLs the contract specified, then calls back to the contract with the retrieved data as an argument. The result is that a smart contract can reference data that lives on an L2 rollup, a database, or any HTTPS endpoint without storing that data on Ethereum mainnet. ENS uses ERC-3668 as the backbone of its L2 name resolution, wildcard subname system, and cross-chain resolver architecture, processing millions of name lookups per year through this pattern as of Q1 2026.
​

The standard was authored by Nick Johnson, ENS founder and Ethereum core contributor, and was finalized as an Ethereum Final EIP in 2022. The pattern is also referred to as the "revert-URL-callback" pattern. It is transport-agnostic: the contract specifies one or more URLs to try in order, and the client uses whichever responds first. The gateway at that URL is called an offchain resolver or CCIP-Read gateway.
​

ERC-3668 enables offchain data lookup through a structured revert-and-callback pattern. A smart contract that needs data it does not store onchain reverts with an OffchainLookup error containing a gateway URL and request payload. The client fetches data from the gateway, re-calls the contract with the response, and the contract verifies it before returning the final answer.
​

No data is stored on Ethereum mainnet. The standard is transport-agnostic: the gateway can be an L2 state reader, a DNS oracle, or any HTTPS endpoint, as long as the callback verification logic can prove the data is correct.
​

The key insight is that Ethereum smart contracts can already verify data without storing it, as long as they have the right verification logic. A contract can verify a cryptographic proof against a known root hash, confirm an ECDSA signature from a trusted signer, or check an L2 state root committed to mainnet. ERC-3668 provides the standardized plumbing for the client-side round-trip: instead of each dapp implementing its own offchain lookup circuit, every ERC-3668-compatible wallet and library handles the pattern automatically.
​

The revert-URL-callback pattern has five steps: call, revert, fetch, callback, and verify. The contract initiates the pattern by reverting with a structured OffchainLookup error. The client reads the revert data, contacts the gateway, passes the response back to the contract in a specific callback function, and the contract performs onchain verification before returning the final result to the caller.
​

In detail, the OffchainLookup revert carries five fields:

The client's ERC-3668 handler, implemented in libraries like ethers.js v6 and viem, catches the OffchainLookup revert automatically and executes the round-trip without application code needing to handle it. This makes ERC-3668 transparent to most dapp developers: they call a contract function, the library handles the revert-fetch-callback cycle, and they receive a result as if the data had always been onchain.
​

The contract's callback function receives (bytes response, bytes extraData) and must verify the response before using it. Verification depends on the trust model: an ENS DNSSEC resolver checks a DNSSEC proof; an L2 resolver checks a Merkle proof against the L2 state root; a database-backed resolver checks an EIP-712 signature from a trusted gateway signer. The verification step is where security lives.
​

ENS adopted ERC-3668 to resolve names whose records live on an L2 rather than Ethereum mainnet. Before CCIP-Read, every ENS record update required a mainnet transaction costing $5 to $50 at peak gas. With CCIP-Read, a name owner stores records on Optimism or Base, updates them for fractions of a cent, and mainnet contracts still resolve them correctly through the callback verification flow.
​

ENS's implementation uses two ERC-3668 patterns: the L2 resolver and wildcard resolution. In the L2 resolver pattern, a name like alice.eth points to an L2 resolver contract. When a client queries the mainnet ENS registry for alice.eth's address, the registry reverts with an OffchainLookup pointing to the ENS L2 gateway. The gateway reads the record from the L2 resolver, wraps it in a proof, and returns it. The mainnet contract verifies the L2 state root proof and returns alice.eth's address.
​

In the wildcard resolution pattern (specified in EIP-2544), a single mainnet resolver contract can answer for any subname under a parent, such as *.alice.eth, by routing all unregistered subnames through a CCIP-Read gateway. This allows unlimited subname issuance at L2 cost with zero mainnet storage per subname. ENS's NameWrapper and the ENS CCIP gateway operated by ENS Labs handle the majority of L2-based name resolution as of Q1 2026, with the ENS app transparently routing users to either mainnet or L2 records.
​

ERC-3668 reduces onchain storage costs for dynamic data by orders of magnitude. Storing 32 bytes in an Ethereum storage slot costs 20,000 gas on first write (SSTORE). At ETH at approximately $2,257 and 10 gwei as of Q1 2026, that single write costs roughly $0.45. Updating it later costs 5,000 gas, about $0.11. For millions of frequently updated records, CCIP-Read eliminates this cost entirely.
​

The tradeoff is latency and a gateway round-trip. A pure onchain read (eth_call) takes one JSON-RPC call to an Ethereum node, typically completing in under 100ms on a local node. An ERC-3668 lookup adds a client-to-gateway HTTP request and a second eth_call for the callback, which typically adds 100–400ms in practice on a well-run gateway. For name resolution, where the data changes rarely and latency tolerances are loose, this tradeoff is clearly favorable. For latency-sensitive onchain paths, such as an oracle price feed used in a liquidation engine, the added round-trip would be unacceptable.
​

The Ethereum community quantified storage costs directly in the context of ENS: an estimated 700 million records that ENS might need to support at full global adoption would cost over $1B to store and maintain on Ethereum mainnet at 2022 gas prices. ERC-3668 makes that cost negligible by relocating record storage to L2 or offchain while preserving mainnet verification guarantees.
​

The CCIP-Read gateway trust model is defined entirely by the callback function's verification logic, not by the gateway itself. A gateway returning unsigned data shifts all trust to the operator. A gateway returning a cryptographic proof from an L2 state root shifts trust to the L2's consensus. The standard imposes no constraints on gateways; security lives in what the contract verifies onchain.
​

Three verification patterns are in common use:
​

The gateway reads a record from an L2 storage slot and returns a Merkle proof against the L2 state root that is committed to Ethereum mainnet. The mainnet callback contract verifies the Merkle proof against the most recently committed L2 state root. Security assumption: the L2's state root commitment mechanism is correct, which is guaranteed by the L2's fraud proof or ZK proof system. Optimism's fault-proof-enabled state roots and zkSync's ZK validity proofs both satisfy this assumption. The delay between an L2 record update and when it can be proven on mainnet depends on the L2's proof finality window.
​

The gateway operator signs the response with a known ECDSA key, and the mainnet callback verifies the signature against the registered signer address. Security assumption: the signer key is not compromised and the gateway operator is honest. This pattern is faster (no state root delay) but requires trusting the gateway operator. ENS uses this pattern for offchain DNS records and for early CCIP-Read deployments before L2 state roots were available on mainnet.
​

For DNS-integrated names (e.g., example.eth linked to example.com), the gateway returns a DNSSEC chain of authority from the DNS root. The mainnet callback verifies the DNSSEC chain. Security assumption: DNSSEC is correctly maintained for the domain, which means the DNS registrar has not been compromised. ENS's DNSSEC Oracle contract (ens-contracts GitHub repository) implements this verification pattern for DNS-linked names.
​

ERC-3668 is general-purpose and has been adopted outside ENS for any situation where a smart contract needs to reference data that is too expensive or too dynamic to store on Ethereum mainnet. The common thread is that the data changes frequently, is large, or is owned by an entity that already maintains a reliable data source elsewhere.
​

A dapp that runs primarily on an L2 but needs mainnet contracts to access its state can use ERC-3668 to expose L2 state to mainnet. For example, a DeFi protocol that tracks user positions on Arbitrum could allow a mainnet governance contract to read those positions via CCIP-Read when computing voting power, without bridging every position update to mainnet.
​

Self-sovereign identity systems like ERC-725 profiles store verifiable credentials off-chain or on L2. CCIP-Read allows a mainnet smart contract, such as a DeFi protocol requiring KYC attestation, to verify a user's credential without the credential itself touching Ethereum mainnet. Veramo and Disco.xyz have prototyped CCIP-Read integration for credential lookups in their verifiable credential frameworks as of Q1 2026.
​

IPFS and Arweave content hashes change when content changes. A contract storing the latest IPFS content hash for a user-maintained webpage can use CCIP-Read to always serve the current hash from an updatable offchain record rather than requiring a mainnet transaction per content update. The IPFS documentation covers content addressing; ERC-3668 provides the bridge between updatable offchain records and smart contract verification.
​

An oracle provider can store price data at scale on an L2 or a Validium (a system that posts data availability commitments but not full data to mainnet), and expose individual data points to mainnet contracts on demand via CCIP-Read. This pattern avoids the cost of pushing every price update to mainnet while preserving mainnet-verifiable proof of accuracy. Redstone Oracle uses a related pull-oracle pattern, and ERC-3668 provides a standardized interface for client-side orchestration of the data fetch.
​

ERC-3668 allows the reverting contract to specify an ordered list of gateway URLs in the OffchainLookup payload. The client tries them in order, falling back if the first does not respond within a timeout. A CCIP-Read deployment can survive a single gateway outage without user-visible failures as long as one URL in the list responds with a valid proof.
​

The URL list format supports templated parameters. A URL like https://resolver.ens.domains/r/{sender}/{data}.json is interpolated by the client: the {sender} placeholder is replaced with the contract address, and {data} is replaced with the hex-encoded callData. This templating lets a single gateway URL pattern handle queries for thousands of different names or records without requiring the contract to embed a separate URL per record.
​

Multiple gateways with independent operators increase censorship resistance. If a single gateway operator refuses to serve a particular query (for compliance, technical, or other reasons), the client can fall back to a community-operated gateway. ENS Labs operates the primary CCIP-Read gateway for ENS, but the ens-contracts documentation explicitly supports community-operated fallback gateways to prevent single-operator dependence. The Ethereum community has debated whether gateway operators can selectively censor responses — the consensus is that any censorship is detectable because a well-formed gateway response must produce a verifiable proof, and a missing or invalid proof signals censorship rather than a missing record.
​

Developers building ERC-3668 systems should implement a minimum of two geographically distributed gateway URLs, each with independent operators, and set a client timeout of 3–5 seconds per URL. The total resolution time including both URLs, if the first fails, stays under 10 seconds — acceptable for ENS resolution and most credential lookups, though not for sub-second financial transaction flows.
​

ERC-3668 is relevant to cross-chain payment systems where routing state or fee schedules live on an L2 or offchain registry. A mainnet contract orchestrating cross-chain stablecoin transfers can use CCIP-Read to query current route availability without replicating that data to mainnet on every update, saving gas on high-frequency routing metadata refreshes.
​

Eco's cross-chain routing infrastructure, which spans 15 chains including Ethereum, Base, Optimism, and Arbitrum, maintains routing metadata that changes as chain conditions shift. CCIP-Read is the standardized mechanism for exposing that kind of dynamic state to mainnet contract callers that need it, without requiring a full onchain data store per chain.
​

ERC-3668's primary limitations are latency, gateway availability, and the trust window between the offchain fetch and the onchain verification. Each offchain lookup adds at least one additional network round-trip compared to a pure onchain call. In practice this is acceptable for name resolution or credential lookups, but it makes ERC-3668 unsuitable as a real-time data source for liquidation engines or high-frequency DeFi automation where every additional millisecond affects outcomes.
​

Gateway availability is a second constraint. If all listed gateway URLs are down, the CCIP-Read lookup fails entirely and the calling contract cannot return a result. Unlike a fully onchain data store, which is available as long as an Ethereum node is running, an ERC-3668 system depends on at least one gateway being responsive. Well-run ENS deployments use three or more geographically distributed gateways to approach the uptime of a pure onchain system, but this requires ongoing gateway operations infrastructure.
​

The trust window is the subtlest constraint. There is a time gap between when the gateway reads the data and when the onchain callback verifies it. For L2 state roots, this gap is bounded by the L2's proof submission latency, which can be 30 minutes to 7 days depending on the L2's proof system. For signed responses, the gap is bounded by the gateway operator's honesty and signing key security. Neither constraint eliminates ERC-3668's utility — they define the appropriate use cases. Time-insensitive data (name records, credentials, routing tables) is well-suited; time-critical price data is not.
​

A further practical limitation is that ERC-3668 is not yet universally supported in lightweight clients. Some mobile wallets and hardware wallet firmware do not implement the OffchainLookup revert handler. Users on unsupported clients receive a confusing raw revert error instead of a resolved name or credential. ENS's ENS app uses a JavaScript client that handles the pattern natively, but third-party integrations must explicitly check for ERC-3668 support before depending on it in critical user flows.
​

Sources and methodology. ERC-3668 specification and finalization history from the Ethereum Improvement Proposals repository. EIP-2544 wildcard resolution from the EIP-2544 specification. ENS contract source from ensdomains/ens-contracts on GitHub. ETH price and gas estimates from CoinGecko and Etherscan, April 2026. Figures refresh quarterly.
​

By Eco research. Updated Apr 2026.
​

CCIP-Read stands for Cross-Chain Interoperability Protocol Read. Despite the name, it is not limited to cross-chain data. It is a general offchain data lookup pattern for Ethereum smart contracts. The "cross-chain" in the name reflects its primary ENS use case of reading resolver data from L2 chains, but the standard works for any HTTPS-accessible data source.
​

It depends on the verification logic in the callback function. If the callback verifies a cryptographic proof (L2 Merkle proof, DNSSEC chain, ECDSA signature from a known key), the gateway is untrusted — it can only return data that passes onchain verification. If the callback does no verification and accepts whatever the gateway returns, the gateway is fully trusted. Most production deployments use at least a signed-response verification scheme.
​

Any wallet or library that uses ethers.js v6 or viem handles ERC-3668 automatically: the library catches the OffchainLookup revert, executes the gateway round-trip, and delivers the callback result to the caller without application code changes. MetaMask's snaps architecture and Rainbow Wallet both support the pattern through their ethers.js integration.
​

A traditional push oracle (like Chainlink Price Feeds) writes data to Ethereum mainnet storage on a schedule, making it available synchronously to any contract. ERC-3668 is a pull pattern: the data is fetched on demand from an offchain source during the transaction flow. Push oracles are simpler for contracts to consume but cost gas on every update. ERC-3668 gateways cost nothing to update but add a client-side round-trip latency of 100 to 400 milliseconds.
​

Yes. ERC-3668 is chain-agnostic. A contract deployed on Optimism, Base, or Arbitrum can emit an OffchainLookup revert just as a mainnet contract does. The gateway and callback model works identically. An L2 contract might use ERC-3668 to read data from a Validium data availability layer, from another L2, or from a traditional database, depending on what the gateway serves and what the callback verifies.
​