The ENS Subgraph was never designed to be a complete view of ENS. It indexes a single chain’s events and exposes them largely as-is — leaving every app that builds on it to work around a long list of gaps. Many apps don’t work around them correctly, and the result is shipping real bugs in some of the most-used software in the ecosystem.
Each of the following limitations is a place where the burden of getting ENS right is pushed onto app developers.
Historically, full access to ENS data required two separate data-fetching strategies working in parallel:
ENS resolution — RPC calls with CCIP-Read support for offchain data (e.g. via viem or wagmi) to perform forward or reverse resolution.Indexed ENS data — the ENS Subgraph, for discovering names owned by an address and all other ENS state outside of resolution. Neither system alone is complete. Resolution gives you resolver records but no access to the rest of ENS state, and it is painfully “close to the metal.” The Subgraph gives you queryable indexed data but cannot resolve names and carries the limitations below. Apps have had to live with the split, its limitations, and its downstream complexity — and with ENSv2, the complexity of ENS’s onchain state meaningfully increases.
The Subgraph does not perform ENS resolution. It has no concept of the ENS Universal Resolver, CCIP-Read, or ENSIP-10 wildcard resolution. Despite this, developers routinely reach for the Subgraph to resolve names — because it’s the indexed data source already in front of them — which produces incorrect results because it doesn’t follow the ENS Forward Resolution protocol .
This isn’t hypothetical. It happens in widely-used software:
Each of these approaches produces results that diverge from what the ENS protocol actually says.
The Omnigraph API performs protocol-correct resolution for you — including the CCIP-Read offchain lookups — so the correct result is the default.
Because the Subgraph can’t resolve names, any app that needs both indexed data and resolution has to run two integrations side by side: the Subgraph for indexed state, and a resolution library for records. You reconcile their differences, their failure modes, and their data models yourself. Developers shouldn’t have to care about these implementation details of the ENS protocol — getting “all the ENS data I need,” whether ENSv1, ENSv2, indexed, or resolved, should come from a single unified API.
The Subgraph’s data model has no concept of ENSv2. The moment ENSv2 launches (Summer 2026), apps still reading the Subgraph are looking at a stale, partial view of ENS — missing the new Namegraph data model entirely. There is no upgrade path: the schema was never designed for it.
The Omnigraph API provides a unified datamodel across ENSv1 and ENSv2: your app works before, during, and after the ENSv2 release without any changes.
The Subgraph indexes a single chain, so it never sees Basenames (.base.eth), Lineanames (.linea.eth), or 3DNS names (.box). A large and growing majority of ENS names already live off of mainnet and are simply invisible to it.
The Omnigraph API indexes the full suite of onchain ENS names, including Basenames (.base.eth), Lineanames (.linea.eth) and 3DNS names (.box).
Beyond being single-chain, the Subgraph has no concept of ENSIP-19 multichain primary names. Even an app willing to query several per-chain Subgraphs cannot reconstruct a name’s primary-name configuration across chains from Subgraph data.
The Subgraph records the resolver assigned to a domain but has no understanding of ENSIP-10 wildcard resolution, and therefore no concept of the effective resolver — the resolver that actually answers for a name via a parent’s wildcard resolver. Apps that read the assigned resolver from the Subgraph and assume it’s the effective one get the wrong answer for any name that relies on wildcard resolution.
The Omnigraph API supports both a Domain’s assigned resolver as well as its ENSIP-10 effective resolver, so you can write applications that understand the difference, whether you’re resolving up-to-date records or letting users edit records onchain.
The Subgraph does not apply ENSIP-15 name normalization. It returns unnormalized labels and names, putting the burden on every consuming app to implement normalization correctly and consistently — and the ones that don’t display or match names incorrectly. ENSNode replaces unnormalized labels for you, so you automatically enjoy safer handling.
The Omnigraph API stores and operates over Interpreted Names , a consistent name format that ensures that names are composed of labels that are either normalized or Encoded LabelHashes . This means consistent handling and fewer application bugs.
Labels in the Subgraph are not stable identifiers. A label that is “unknown” today can become “known” later (as label-healing coverage grows), and the set of normalizable names can change over time. Apps that key on label or name strings will see identifiers shift underneath them. The only stable identifier is the node (the namehash of the name) — but the Subgraph schema surfaces it as the id field, and getting this right requires careful, documented handling. See Use the node as the stable identifier .
The Omnigraph API provides stable identification via a Domain’s id, a multichain-aware globally unique identifier that works for both ENSv1 and ENSv2 Domains. Domains are also addressable by InterpretedName , and a Domain’s Canonical Name (Domain.canonical.name) is always maximally healed at request time, thanks to ENSRainbow .
The Subgraph schema spreads ownership across multiple fields — owner, registrant, wrappedOwner — reflecting raw protocol state (the Registry, the .eth Registrar, and the Name Wrapper). Determining the effective owner of a domain requires understanding the interplay of all of them. This is exactly the kind of protocol-implementation detail app developers are forced to learn and re-implement, with plenty of room to get it wrong.
In the Omnigraph API Domain.owner is always the effective owner’s address — no weird edge-cases! For ENSv2 Domains, Domain.owner is Smart-Account-aware and represents the true owner of the Domain at a given time.
The Subgraph indexes onchain events only, so it has no knowledge of offchain ENS names. A meaningful and growing slice of ENS lives offchain and is entirely absent from Subgraph data.
While the Omnigraph API doesn’t (yet! ) index offchain names, it does provide protocol-correct Accelerated Forward Resolution, including support for offchain CCIP-Read-based names.
The Subgraph exposes raw values straight from the ENS protocol, with none of the interpretation that apps actually need:
Address records may be for non-EVM chains and need chain-specific decoding before they’re usable.Contenthash values are encoded and need decoding to become a usable URL.Text records are represented by users in many inconsistent ways. Consider the many variations in how someone might set a Twitter/X handle — both the record key and the value vary widely. Every bit of this interpretation, decoding, and normalization is left to the app developer. The result is more bugs in ENS integrations across the ecosystem, which damages the network effects and growth of ENS.
The Omnigraph API will support two major record resolution use-cases:
Protocol-accurate ‘raw’ requests, without post processing, and
Consumer-friendly semantic interpretation of records for, e.g. profile display.
A common and important flow is taking an NFT reference as input and mapping it: NFT Ref → Domain → Name → Avatar text record → Avatar image. This powers services like the ENS Metadata Service, which provides NFT metadata for ENS names using standardized protocols adopted by platforms such as OpenSea, Rarible, Grails, and ENS Vision. The Subgraph’s raw, resolution-free data model makes this flow far harder than it should be.
The Omnigraph API will support automatic avatar url derivation; all your app will need to do is render an <img /> tag!
The Subgraph (and any data-level-compatible indexer) contains a large volume of unhealed names — names whose labels are only known as labelhashes (e.g. [abcd…].eth). These complicate both the developer experience and the UX of every app built on top, which must decide how to display and handle them.
What the heck is a [428…b0b]? These are encoded labelhashes used to represent an unknown label in an ENS name. Without name healing, millions of names in the ENS manager app (and other ENS apps) don’t appear properly. See the problem for yourself: Example 1 and Example 2 .
ENSNode already heals ~94% of these labels with ENSRainbow , compared to ~11% with the label set bundled into the traditional ENS Subgraph. ENSRainbow has data for healing 259,053,605 unknown labels as of May 2026, and coverage is climbing toward a 99% target.
Healing turns these encoded labelhashes back into the readable labels they represent, so a name like [428…b0b].makoto.eth is displayed as the actual name a user expects.
See ENSRainbow for how ENSNode uses this service to heal labels at request time.
Achieving common ENS query operations correctly against the Subgraph requires meaningful additional logic. In practice that logic lives in “thick client” libraries — most notably ensjs, which embeds special-case handling for working with the Subgraph (e.g. decoding names, reconstructing histories, assembling the queries for names owned by an address). A thin client that simply wraps the GraphQL API can’t reproduce these behaviors. And because such thick clients are written for a single language (ensjs is TypeScript only), developers building on ENS in any other language don’t get them at all.
The Subgraph’s auto-generated GraphQL API ships without a first-class, type-safe client. Developers are left hand-writing queries and types, with no compile-time guarantees that a query matches the schema or that responses are shaped as expected.
Beyond the data-model limitations, the Subgraph’s auto-generated GraphQL API leaves common operational needs underserved:
Pagination is awkward and easy to implement incorrectly at scale.Caching has no first-class story for ENS-shaped data.Indexing status is hard to reason about — there’s no clear, app-friendly signal for how far behind realtime the data is (e.g. worst-case distance from the chain head).Joins in the auto-generated API perform certain multi-entity operations in ways that don’t match what apps actually need, forcing client-side stitching.
The Omnigraph API supports Relay Connections for paginated resources; your app gets lightning-quick infinite scroll with minimal work! If using enskit (React)useOmnigraphQuery hook comes with Omnigraph-specific local cache directives for instant resolution of cacheable values. The Omnigraph’s idiomatic GraphQL API also aims to match consumer query patterns as closely as possible to negate complex and bespoke client-side logic; if your use-case isn’t yet supported, open an issue on GitHub .
ENSNode supports the Indexing Status API for up-to-date knowledge of ENSNode’s indexing status, including realtime lag, if any.
Indexed ENS data is vital for the upcoming launch of ENSv2. The legacy ENS Subgraph is fundamentally unsuitable for ENSv2, and a replacement is critically required for many of ENS’s most important apps — including the official ENS Manager App. Build on the Omnigraph API or the Unigraph datamodel to take the guesswork out of your ENS integration.
