Skip to content
ENSNode

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:

  1. ENS resolution — RPC calls with CCIP-read support for offchain data (e.g. via a popular package such as viem or wagmi) to perform forward or reverse ENS resolution.
  2. Indexed ENS data — the ENS Subgraph for indexed ENS data, such as discovering names owned by an address and all other ENS state outside of ENS resolutions.

Neither system alone was complete.

  • ENS resolution gives you resolver records, but no access to all the other state about ENS! ENS Resolutions as exposed through popular libraries such as viem and wagmi are also painfully “close to the metal”, putting the burden on app developers to learn and carefully implement complex details about interpreting raw values returned by the ENS protocol.
  • The Subgraph gives you queryable indexed ENS data but has critical limitations, including:
    • The Subgraph is single-chain.
    • The Subgraph has no support for ENSv2’s fundamental data model changes.
    • The Subgraph cannot perform ENS resolutions.
    • The Subgraph doesn’t understand key implementation details of the ENS protocol such as ENSIP-10, ENSIP-19, ENS name normalization (ENSIP-15), etc.
    • The Subgraph exposes too many internal implementation detail complexities of ENS for app developers.

In the past, apps building on ENS have had to live with these split fetching strategies, their limitations, and their downstream complexities. And we should note, with ENSv2, the complexity of ENS’s onchain state space meaningfully increases.

How ENSNode solves this

Section titled “How ENSNode solves this”

ENSIndexer offers the unigraph plugin, which builds a unified polymorphic indexed data model in ENSDb of multiple ENSv1 Nametrees (the ENSv1 onchain state model found in the ENS root registry, Basenames on Base, Lineanames on Linea, 3DNS on Optimism, etc.), and the ENSv2 Namegraph (the ENSv2 onchain state model that ENSv1 domains may optionally make a dynamic upgrade to, and may contain cycles, disjoint domains, and allows domains to dynamically reposition themselves across time within the ENSv2 Namegraph).

The ENS Omnigraph API is delivered by the ENSApi service which provides a highly tailored GraphQL API that builds upon and refines the “unigraph” indexed data model held in ENSDb to deliver all your ENS data access needs in a single API endpoint. The ENS Omnigraph API also understands ENS protocol implementation details including ENSIP-15 (ENS name normalization), ENSIP-10, ENSIP-19, and much more so that you can focus on building your app and not all the internal implementation complexities of the ENS protocol.

  • ENS Resolution — The ENS Omnigraph API, through ENSApi, internally implements the ENS Universal Resolver on top of the indexed ENS Unigraph datamodel 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. Your ENS resolutions may now also be faster than ever!
  • Indexed ENS data — Access the multichain indexed “unigraph” state model all within a single unified, polymorphic API-level state model that understands ENS protocol implementation details including ENSIP-15 (ENS name normalization), ENSIP-10, ENSIP-19, and much more so that you can focus on building your app and not all the internal implementation complexities of the ENS protocol.

What you need to do

Section titled “What you need to do”