ENSv2 Readiness
Historical limitations of building on ENS
Section titled “Historical limitations of building on ENS”Full access to ENS data formerly required two separate data-fetching strategies working in parallel: ENS resolution (RPC calls with CCIP-Read, e.g. via viem or wagmi) and indexed ENS data (the ENS Subgraph). Neither system alone was complete — resolution is “close to the metal” and the Subgraph carries a long list of Key Limitations. And with ENSv2, the complexity of ENS’s onchain state space meaningfully increases.
How ENSNode solves this
Section titled “How ENSNode solves this”The Unigraph Data Model — ENSIndexer’s unigraph plugin builds a single, unified indexed data model in ENSDb that combines all of ENSv1 — mainnet .eth, Basenames on Base, Lineanames on Linea, 3DNS on Optimism — together with ENSv2. One data model, every chain, both protocol versions.
The Omnigraph API — The ENS Omnigraph API, delivered by ENSApi, is a fully typed GraphQL API on top of that Unigraph data model. It handles the ENS protocol’s many implementation details for you, so you can focus on building your app instead of wiring up the protocol’s internals.
Accelerated ENS Resolution — The ENS Omnigraph API, through ENSApi, internally implements the ENS Universal Resolver on top of the indexed ENS Unigraph data model in ENSDb. We refer to this idea as “ENS Protocol Acceleration”. For cases where ENS Resolution requires offchain data, ENSApi internally performs the CCIP-read operations on your behalf to ensure every resolution request accurately follows all ENS protocol standards. No need for any RPC calls in your app, and your ENS resolutions for indexed names could speed up by an order of magnitude or more!
What You Need to Do
Section titled “What You Need to Do”Resolving Records — If you’re exclusively interested in resolving ENS names, you need to ensure that your resolve RPC calls go to the new UniversalResolverV2 contract or risk stale and incorrect results being returned. Depending on your situation, this update may be handled simply by updating viem or wagmi, but for many apps building on indexed ENS data or with more advanced requirements, additional upgrade actions may be required.
For many, the simple solution for ENSv2 readiness will be to adopt the ENS Omnigraph API from ENSNode for all their ENS data needs (both ENSv1 and ENSv2). ENSNode also provides ENS Protocol Acceleration, dramatically reducing resolution latency for most names.
Querying ENS Data — If you’re querying ENS names via a legacy API such as the ENS Subgraph you need to update to an ENSv2-ready service like ENSNode; as soon as ENSv2 launches, data served by the Subgraph (and any ENSv1-only indexers) will be instantly unreliable for the true state of ENS.
Pick Your Integration
Section titled “Pick Your Integration”ENSNode meets you wherever you are — drop-in React components, a typed TypeScript SDK, raw GraphQL, direct ENSDb access, CLI tooling, or AI agent integration. Pick the surface that fits your stack and ship ENSv2-ready code today.