Omnigraph: names pointing to this address

[shrugs]

Problem

Portal's /addr/$addr/resolution view ("names pointing to this address") today is served by ensjs subgraph's getResolvedNamesForAddress. As Portal migrates off subgraph stitching, Omnigraph needs to cover this query.

Proposal

Expose forward-resolution lookup on Account as a Relay connection over a new NameReference type, with an optional coinType filter:

type Account {
  nameReferences(
    where: AccountNameReferencesWhereInput
    first: Int, last: Int, before: String, after: String
  ): NameReferenceConnection!
}

input AccountNameReferencesWhereInput {
  coinType: CoinType!
}

type NameReference {
  name: String!                    # InterpretedName of the Domain whose addr() points here
  coinType: CoinType!              # the CoinType of the matching addr() record
  match: Boolean!                  # ENSIP-19 reverse(address, coinType) === name (indexed-only)
  normalized: Boolean!             # isNormalizedName(name)
  resolverAddress: Address!        # the Resolver holding the matching addr() record
  resolverChainId: ChainId!        # chain where that Resolver lives
}

Notes

• where is optional — when omitted, return matches across all coinTypes; when supplied, scope to a single coinType. Default-coinType records (coinType = DEFAULT_EVM_COIN_TYPE) are returned as ordinary rows, not specially expanded.
• v1 reflects literally-indexed records only: no Forward Resolution / CCIP-Read, no ENSIP-19 default address record expansion, no *.addr.reverse-based primary name walk for match. match uses the indexed StandaloneReverseRegistrar shortcut (default.reverse / [coinType].reverse).
• v1 does NOT enforce active-resolver consistency — records on resolvers no longer assigned to the Domain may surface. (Tracked separately.)
• New (value, coinType) index on resolver_address_records for the access pattern.

Blocker / Open question: node → Domain reverse mapping

The natural query reads resolver_address_records (keyed by (chainId, resolver, node, coinType)) and joins to a Domain to attach a Name. In ENSv1, subgraph_domain.id = node (and domain.node is set), so the join is trivial. In ENSv2, node is no longer a functional reference to a Domain — it's only knowable when you start from the Name and namehash forward. The corresponding Domain entities exist conceptually but their namehash is not materialized in the database.

Confirmed empirically against ens-test-env (v2-native, default SUBGRAPH_COMPAT=false): 15 records for (value=DEVNET_OWNER, coinType=60), 0 join matches.

To support reverse lookup natively, we'd need to materialize a canonicalNode for every Domain (the namehash of its full canonical path) and maintain it as the canonical path changes. It is not obvious this is feasible in Ponder at ENS scale: every parent canonical-path mutation cascades to all descendants' canonicalNode values — potentially a very large fan-out write per event, hot in the indexer critical path. Designs to consider: incremental/lazy recompute, deferred recompute jobs, cap-and-warn on deep subtrees, etc. This needs its own investigation before this PR can ship its intended shape.

Consumers

• apps/portal/ /addr/$addr/resolution

Alternative shapes if canonicalNode materialization is infeasible

If the reverse mapping can't be made sustainable, the endpoint can still be useful in narrower forms — these are not interchangeable with Portal's current discovery UX, but each has real callers:

1. Records-only primitive. Drop name from the response; return (resolverChainId, resolverAddress, node, coinType) and let the caller hydrate names via their own index. Useless for Portal's specific UI; useful as a building block for tools that already have a name index.
2. Filter-by-candidates. Flip the direction: Account.nameReferences(where: { coinType, names: [InterpretedName!]! }). Caller supplies candidate names; we namehash each and check the records. Solves "verify these names point at this address"; does not solve discovery ("find names I don't already know about").
3. Owned-and-pointing intersection. Extend Account.domains with where: { resolvesTo: AccountAddressInput }. Filters owned Domains down to those whose addr record points to a given address. Limited to names the user owns, but covers the common case for an address page.
4. Subgraph-compat-only. Ship the field gated on SUBGRAPH_COMPAT=true; document that v2-native deployments return empty until canonicalNode materialization lands. Useful for deployments running the legacy compat plugin; silent footgun in v2-native deployments unless we error visibly when not compat-enabled.

Open question: which of these (or which combination) actually serves Portal — and is it worth shipping any of them before the canonicalNode work, or do we wait?

Prior context

• Initial spec / iteration: see Omnigraph: names pointing to this address #1962 (comment) and Omnigraph: names pointing to this address #1962 (comment).
• A first implementation pass joined domain_resolver_relations.domain_id = resolver_address_records.node, implicitly assuming the ENSv1 model where domainId ≡ namehash. That silently returns zero rows in any v2-native deployment.

[coderabbitai]

🔗 Related PRs

#1575 - fix: add correct ensv1 and ensv2 addresses to sepolia-v2 namespace [merged]
#1654 - feat: implement canonical filter for findDomains [merged]
#1658 - ENSv2 API: Introduce Domain.subdomains [merged]
#1670 - ENSv2 Integration Updates [merged]
#1733 - ENSv2: Index ENSv1 Manager and Surface via API [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[shrugs]

While prototyping this against the canonical ENSIndexer schema, we hit a fundamental data-model issue worth surfacing before anyone picks this back up.

The problem

The natural query — "given an address, find all addr(coinType) Resolver Records pointing at it" — returns rows from resolver_address_records keyed by (chainId, resolver, node, coinType). To produce a Name for each match, we need to map node (a namehash) back to a Domain row.

In ENSv1 this is trivial: subgraph_domain.id = node, and domain.id = ${ENSv1RegistryId}/${node}, and domain.node is populated. The reverse lookup is a JOIN ... ON d.node = rar.node.

In ENSv2 this mapping doesn't exist. node is no longer a functional reference to a Domain — it's only knowable when you start from the Name and namehash forward. The Domain entities corresponding to a given node exist conceptually, but their namehash is not materialized in the database. The canonical domain table has node populated only for ENSv1Domain rows; ENSv2 domains use a CAIP-19 ${chainId}/erc1155:${contract}/${tokenId} ID with node = NULL. domain_resolver_relations.domain_id is the full DomainId string, not a namehash, so it can't be joined to rar.node either.

Confirmed empirically against ens-test-env: 15 resolver_address_records rows for (value=DEVNET_OWNER, coin_type=60), 0 matches when joined to either subgraph_domains (empty when SUBGRAPH_COMPAT=false, the default) or domains.node (no v2 rows have node set, and the v1 rows are all *.addr.reverse entries, not *.eth).

The toy-indexer assumption

A first-pass implementation joined domain_resolver_relations.domain_id = resolver_address_records.node and used domains.node for the active-resolver / name lookup. That implicitly assumes the ENSv1 model where domainId ≡ namehash. It silently returns zero rows in any v2-native deployment, which is the default for new ENSIndexer instances. Any approach that starts from a node and tries to recover a Name without an explicit materialization step will hit this.

Paths forward

1. Materialize node for v2 Domains at index time. Add a node column to the canonical domain table populated for both v1 and v2 (computed from labelHash + parent's node walking the canonical-path chain when the Domain is created/updated). Once that exists, the original JOIN ON d.node = rar.node works for both v1 and v2. Cleanest long-term fix; unblocks any future "given a namehash, give me a Domain" query, not just this one.
2. Subgraph-compat only. Ship the field gated on SUBGRAPH_COMPAT=true. Useful for legacy-compatible deployments, useless in v2-native ones.
3. Filter-by-candidates. Flip the direction: Account.nameReferences(where: { coinType, names: [InterpretedName!]! }). Caller supplies candidate names, we namehash each and check the records. Solves "verify these names point here" but not the discovery case the subgraph version solves.
4. Records-only primitive. Return (resolverChainId, resolverAddress, node, coinType) with no name resolution. Honest about what's queryable today; not useful for Portal's specific UI without an external node→name index.

(1) is the right long-term move. Suggest landing this PR's Account.nameReferences field after the domain.node materialization is in place, rather than shipping a v1-style implementation that silently returns empty in the default ENSv2 setup.

[shrugs]

Sharpening (1) above: it's not just a node column on Domain — we'd need to materialize a canonicalNode for every Domain (the namehash of its full canonical path), maintained as the canonical-path changes (renames, parent re-parenting, registry swaps). And it's not obvious this is feasible in Ponder at ENS scale: every parent canonical-path mutation cascades to all descendants' canonicalNode values, which is potentially a very large fan-out write per event, hot in the indexer's critical path.

So (1) isn't a free fix — it's a real design question (incremental recompute, lazy materialization, deferred recompute job, etc.) before we know whether it can actually be sustained on mainnet-scale event throughput.

[shrugs]

materialization of canonicalNode is now complete and this issue is unblocked