Skip to content
ENSNode

ENS Subgraph API Compatibility

ENSNode v1 provides an ENS Subgraph-Compatible GraphQL endpoint for the purposes of:

  1. Demonstrating 1:1 reproduction of the ENS Subgraph’s logic & data
    • the ENS Subgraph has been adopted by the community as an important resource for ENS protocol data, and confidence in ENSNode’s implementation is demanded
  2. Plug-and-Play compatibility for those that wish to host their own ENS indexer
    • deploying ENSNode is faster and easier than running an ENS Subgraph instance
    • 100% compatibility with ensjs eases community adoption of ENSNode
  3. Gradual migration from the subgraph
    • users may wish to gradually migrate from the subgraph & its api to ENSNode’s api
    • the built-in Ponder GraphQL api provides more efficient querying (esp. pagination) semantics
    • the built-in @ponder/client provides a smoother devx for retrieving data within a client app

Compatibility Tooling

Section titled “Compatibility Tooling”

ENSNode has developed tooling to verify subgraph compatibility and ease migration from the ENS Subgraph.

Subgraph Compatibility Tooling

Subgraph-Compatible GraphQL API Reference

Section titled “Subgraph-Compatible GraphQL API Reference”

Supported Features

Section titled “Supported Features”

The feature set used by ensjs and ens-app-v3 is fully supported: see the well-known queries section below.

There exists a fork of ens-test-env that uses ENSNode instead of the ENS Subgraph. It’s this fork of ens-test-env that is used to run the ensjs test suite against ENSNode.

Planned Features

Section titled “Planned Features”

Possible Features

Section titled “Possible Features”

The following features could be implemented, but are not yet planned.

Unplanned Features

Section titled “Unplanned Features”

The following features of the subgraph graphql api are explicitly unsupported and are not planned.

Well-Known Queries

Section titled “Well-Known Queries”

These are some of the popular queries we’ve seen in the wild (namely via ENSjs and ens-app-v3)—the Subgraph-compatible GraphQL API includes full compatibility with these use-cases (and all other possible queries with the exceptions listed above).

from ensjs

Section titled “from ensjs”
  • getDecodedName — Gets the full name for a name with unknown labels from the subgraph
    • Heals encoded labels using the subgraph
    • Returns if name is fully decoded
    • Splits name into labels
    • Finds domains by id for encoded labels
    • Queries domain by namehash
  • getNameHistory
    • Retrieves all events associated with a name
  • getNamesForAddress
    • Gets all names related to an address via registrant, owner, wrappedOwner, resolvedAddress
    • Supports searchString
    • Supports filtering by expiry, reverse records, empty domains
    • Supports ordering by expiry date, name, labelName, createdAt
    • Supports pagination by excluding previous results
  • getSubgraphRecords — Gets the records for a name from the subgraph
    • Allows querying by specific resolver id
  • getSubgraphRegistrant — Gets the name registrant from the subgraph
    • Supports .eth second-level domains only
  • getSubnames — Gets the subnames for a name
    • Supports searchString
    • Supports filtering by expiry, empty domains
    • Supports ordering by expiry date, name, labelName, createdAt
    • Supports pagination by excluding previous results

from ens-app-v3

Section titled “from ens-app-v3”