ENS.Tools doesn't run its own ENS indexer. Building one is real work — keeping it in sync with mainnet, indexing the wrapped registry, recovering hashed labels — and it isn't what we want to spend our time on. What we want to spend our time on is the user experience: the marketplace, the expiry explorer, the public profile pages, the bulk operations, the MCP server for AI agents.
So we use ENSNode from NameHash Labs — and several adjacent services from the same family — to handle the indexing layer. This post is a quick tour of which parts of ENS.Tools are powered by which service, so you know what is ours and what is theirs.
ENSNode (the subgraph)
Every read path on ENS.Tools hits ENSNode first. The Expiry Explorer's three lifecycle tabs, the marketplace metadata, the public profile pages at /u/<name>, the Farcaster Frame at /frames/expiry, and 9 of our 27 Netlify functions all start with a GraphQL query to api.alpha.ensnode.io/subgraph.
It is the same shape as the legacy ENS subgraph (GraphQL, BigInt-typed timestamps, familiar entity model) but it's actively maintained, hosted free, and built with ENSv2 in mind. The 50,000-row PostgREST limit on the old gateway never showed up here — we have paginated through every active .eth registration without issue.
ENSRainbow (label healing)
The subgraph indexes most names by their preimage (vitalik.eth) but some come through as labelhashes — [0xaf2caa1c…].eth. Those are names whose string form the indexer couldn't recover from on-chain events alone.
ENSRainbow maps known labelhashes back to their string. We call it in five places: the AI Search results, the Expiry Explorer's grace + temp-premium queries, the public profile subname list, the Farcaster Frame's name candidates, and the marketplace listing flow. The Frame in particular benefits — before Rainbow, we were silently skipping bracketed-label registrations; now they show up as readable names whenever Rainbow knows the preimage.
NameGuard (security analysis)
ENS names can be visually confusing. vitalik.eth and vіtalik.eth (the second one uses a Cyrillic і) render identically in a lot of fonts. Buying the wrong one is a real way to get phished.
NameGuard runs a battery of checks — homoglyph detection, unnormalised codepoints, mixed-script flags, fake-checkmark suffixes — and returns a structured rating. We surface that on every domain detail page and call it from the AI Search results so suspicious names show a warning before the user clicks through.
web3.bio (linked identities)
An ENS name is an identity. web3.bio cross-references that identity across Lens, Farcaster, X, GitHub, Linkedin — anywhere a profile is verifiably linked back to the same wallet. The "Linked Identities" row on every public profile page is theirs.
What is ours
The consumer surface, the editorial, the marketplace, the bulk operations:
- Marketplace — Seaport orderbook, 2% atomic fee, no off-chain custody. Listings are aggregated from Reservoir plus our own database.
- Expiry Explorer + per-category landing pages — built on the ENSNode subgraph but with our own client-side filtering, decay-pricing, sorting, and per-collection segmentation.
- Public profile pages — the sunburst portfolio chart, the registration heatmap, the collection tags, the share card, the rarity scoring. All ours.
- Bulk operations — bulk renew, bulk edit records, bulk wrap, bulk list. Multicall builders we wrote against the ENS registrar contracts directly.
- MCP server with a live, discoverable ENS tool catalogue at
/mcp. Lets AI agents query ENS without us having to host a public API — they hit the MCP, we proxy out to ENSNode for them. - Farcaster Frame — live snapshot of today's most-grabbable temp-premium names, refreshed every minute.
Why this matters
ENS as a protocol is open. Anyone can read the registry, anyone can write to it. But the experience layer on top has historically been fragmented — one tool for managing records, another for buying, a third for tracking expiries, a fourth for searching. The reason fragments persist isn't that the protocol is closed; it's that the infrastructure work (indexing 100M+ events, healing labels, monitoring for fake names) is hard.
ENSNode making that work public and free is what lets a small team like ours build a polished consumer surface without first having to be an indexing company. The next generation of ENS apps will look more like ENS.Tools — composed of public infra, focused on a specific user — and less like the all-in-one platforms that had to roll their own indexer to ship anything.
If you're building too
Use ENSNode for reads. Use ENSRainbow when a name comes through hashed. Use NameGuard before showing a name to a user. Use Seaport or Reservoir for marketplace transactions. Use the standards — ENSIP-25 for AI agent identity, ERC-7828 for multi-chain addressing — because the same audience reads them.
And if your project does something we haven't thought of, tell us. The benefit of the protocol being open is that complementary surfaces strengthen each other.
The full attribution list is in the footer of every page on the site, and in /llms.txt for the AI agents reading along. If we missed your service and you can prove we depend on it, let us know.