Indexing ENS‐Compatible On‐Chain Names
Accessing on-chain data
Fetching data about on-chain activity can be either done via direct RPC calls to a blockchain node, or via an API service that has previously indexed the on-chain data. Using direct RPC calls loads data directly from the source of truth, but it’s also more complex and the data may not be in the caller’s preferred format or structure. Using an API service is more flexible, because it abstracts away the data transformation process and allows the clients to query a set of prepared aggregates.
ENS and the eth top-level domain
Indexing on-chain data
The ENS community has adopted the Graph Protocol and built the ENS Subgraph to index on-chain data about ENS and the eth subnames. The indexing engine sources data from an RPC node, and aggregates it into a set of collections. The main collections describe following data entities:
- Account
- Domain
- Registration
- Resolver
- WrappedDomain
Serving aggregate data
Clients that want to access ENS data can easily do so with the ensjs client library. The ensjs lib queries both an RPC endpoint and, for more complex functions, the the ENS Subgraph deployment. This deployment has a GraphiQL interface if you’d like to interact with it and check out the data model it offers.
Other ENS-compatible protocols
The canonical ENS protocol has been originally deployed on the Ethereum Mainnet. There are plans to scale the protocol with its own layer-2 chain, called Namechain.
Some members of the ENS community have started building their own ENS subname systems on top of the CCIP-read protocol, for example:
These L2 systems run their own copy of ENS-compatible contracts and represent a multi-chain extension of the unified ENS namespace. A core design goal of ENSNode is to index ENS names whever they live, whether that’s on-chain (on mainnet or L2s like Base, Linea, and Namechain) or off-chain (ex. .cb.id, .uni.eth).