ERC-3668 primary sources — 2026-05-11

Project status in this pass

• No standalone ERC-3668 whitepaper or litepaper surfaced.
• The clearest primary materials were the final ERC text, the raw ERC markdown, ENS’s CCIP Read documentation, and ENS’s offchain-resolver repository README.
• The sources consistently frame ERC-3668 as a lower-layer offchain-read transport and callback-validation primitive, not as an ENS-only feature.

Primary-source snapshots

1) Final ERC text

• URLs:
  • https://eips.ethereum.org/EIPS/eip-3668
  • https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-3668.md
• Key excerpt/signals:
  • Contracts can revert with OffchainLookup(sender, urls, callData, callbackFunction, extraData) instead of directly returning data.
  • Clients then query a gateway and call the specified callback on the original contract with the gateway response and original context.
  • The contract is responsible for decoding and validating the returned data with an implementation-specific method.
• Why it mattered:
  • This is the clearest statement that ERC-3668 standardizes the fetch/return/verify loop itself rather than any one data source or storage system.

2) Gateway interface and client protocol in the ERC

• URLs:
  • https://eips.ethereum.org/EIPS/eip-3668
  • https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-3668.md
• Key excerpt/signals:
  • The ERC specifies URL templating with {sender} and {data}, GET-versus-POST behavior, JSON response shapes, HTTP error handling, multi-URL failover, and recursive-lookup limits.
  • The spec requires sender checks so clients reject bubbled nested OffchainLookup errors that do not originate from the contract actually being called.
• Why it mattered:
  • These details show that the real control plane is not just “offchain data exists,” but gateway routing policy, client-library support, callback validation, and nested-call safety.

3) ENS CCIP Read docs

• URL: https://docs.ens.domains/resolvers/ccip-read/
• Key excerpt/signals:
  • ENS docs explain that by leveraging EIP-3668 in a resolver, developers can defer ENS resolution to an L2 or offchain API while keeping resolution transparent to wallets and applications.
  • The docs explicitly describe the resolver revert, gateway fetch, and callback-validation loop.
  • ENS also distinguishes more trusted signed-gateway models from more trustless proof-based gateway designs.
• Why it mattered:
  • This is the best practical demonstration that ERC-3668 is not just an abstract standard: it underpins a real-world name-resolution stack where transport, signer/proof choice, and client support all matter.

4) ENS offchain-resolver repository

• URLs:
  • https://github.com/ensdomains/offchain-resolver
  • https://raw.githubusercontent.com/ensdomains/offchain-resolver/master/README.md
• Key excerpt/signals:
  • ENS’s repo splits the system into a resolver stub contract and a Node.js gateway server.
  • The gateway looks up records in a backing store and signs responses.
  • The resolver verifies signatures from authorized signers and returns the answer, including support for ENS wildcard resolution.
• Why it mattered:
  • This makes the deployment model concrete: ERC-3668 transport alone is not the full system; signer custody, backing-store policy, and resolver verification logic become the real trust surface.

Working conclusion

ERC-3668 belongs in the corpus because it isolates the lower-layer offchain-read primitive beneath ENS offchain resolution and other gateway-mediated verification systems. The durable insight is that many “cross-chain,” “offchain,” or “verified external data” products differ less in the fact that they fetch data externally than in where the real authority sits: gateway operators, signer keys, proof services, callback contracts, and client defaults.