perf: canonical-registries CTE scales with # of ENSv1 Domains after eager virtual-registry init

[shrugs]

Problem

Portal's /$name/resolver view needs the "underlying" resolver address when the configured resolver is a proxy / composite resolver. Today this is done with two RPC hops: supportsInterface(CompositeExtendedResolver) to detect the case, then ensjs getUnderlyingAddress to unwrap. As portal migrates off RPC, Omnigraph should expose this directly.

Proposal

Expose on Resolver:

type Resolver {
  # existing fields...
  underlying: Resolver             # null when not a proxy / composite
  isComposite: Boolean!            # convenience flag
}

• underlying points at the Resolver entity the proxy delegates to (same node type, so all existing resolver fields are available on it).
• isComposite short-circuits the common "is this a proxy?" UI check.

Notes

• If an underlying resolver is itself a proxy, underlying should chain (a single .underlying.underlying walk suffices; indexer can eagerly resolve to the terminal resolver if cheaper).
• Current detection: interface ID 0xc7e45d73 (CompositeExtendedResolver).

Consumers

• apps/portal/ /$name/resolver
• apps/portal/ features/resolver/hooks/useUnderlyingResolver.ts (current RPC path)

References

• Tracked in PORTAL_DATA_REQUIREMENTS.md §3 item 3.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Omnigraph: Resolver.underlying (unwrap proxy / composite resolvers) #1964

---

📝 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!