ENS Research: Namechain, ENSIP-19 & Multichain Interop

[estmcmxci]

@cap

We currently have at least 3 L1 chains that are interested (or semi-interested) in launching a native naming/identity layer for their chain. The problem is, there’s no straightforward way to do this directly on their chain today.

Cool. To stress this point — as far as I know, there’s currently no minimal, common verifier interface that allows data to be proven back to Namechain in a standardized way.

This puts the burden on each chain to build its own bespoke proof verifier.

Since different chains (perhaps even the ones you’re referring to, Cap) generate proofs in different formats, ENS needs a shared interface that all verifiers can implement.

—

Justifying the ‘Scaling with Trust’ Model:

@estmcmxci

External systems — from other L1s to non-EVM chains and DNS — can be treated as verifiable data ‘at the edge,’ connected back to Ethereum through proofs, once the necessary standards are defined.

Introducing a minimal verifier interface in an ENSIP would make this possible: modular, scalable, and standardized across environments. It would reduce R&D overhead for new chains, make integrations easier, and enable better discoverability.

—

@cap

Offchain approach works, but it limits the ability to generate onchain transactions (important metric for young chains) and restricts opportunities to generate revenue from registrations and renewals (another important thing for them).

I don’t think there’s a strong enough economic incentive for most chains to implement native identity or naming systems themselves.

Their main economic upside still comes from sequencer fees and transaction throughput — not from naming or registration revenue, which likely contributes less than 5% of overall onchain activity.

That’s why it makes sense for ENS (via Namechain and standardized verifiers) to shoulder the interoperability work — chains get identity as infrastructure, without having to justify it economically.

—

@cap

It’s also worth noting that implementing this at the chain level could chip away from economic activity on Namechain, reducing its own onchain actions, so this trade-off deserves some consideration.

ENS’s mission is to connect with the global namespace. Essentially, ENS acts as a bridge between traditional internet infrastructure and decentralized infrastructure across various blockchains. Economic activity on Namechain should therefore remain subordinate to this mission.

In this sense, fees serve primarily as a coordinating mechanism, with Namechain providing the economic substrate for the bridge between “Web2” and “Web3.”

—

@raffy

The routes to the wildcard L2 primary name resolvers (ChainReverseResolver) can be mapped under a different namespace. eg. if the “wide” coinType (256 bit hash) approach is standardized, we can simply add additional routes like: b54922573c27697c1a45fbdb04f41f3730976a59486c4ede520802964d3ca8ab.reverse instead of 80000001.reverse.

Ah, okay. So ENS can handle reconciliation through its existing reverse lookup structure by using distinct namespaces. By standardizing a wider coinType field, ENS could use deterministic hashed identifiers inside .reverse instead of numeric labels.

This effectively bridges ENSIP-19 and existing chain-ID standards (like CAIP-2 or SLIP-44) by mapping those external IDs into ENS’s reverse namespace in a consistent, collision-resistant way.

Is work already underway? Feels like this can be made into a priority as well.

—

@raffy

Currently, the Unruggable verifiers lack a standard resolver interface. For ENSv2, I am experimenting with some new introspection tech.

Very interesting! By exposing child resolvers, a standard resolver interface could act as a router favoring a composite, introspective model for cross-environment resolution and verification rather than a single, uniform verifier interface.

Given how finality and proof formats vary across environments, developing a minimal verifier interface seems difficult. Still, I wonder if there’s been any research into a hybrid approach: where the composite model coexists with a lightweight meta-standard for discoverability and replay safety.

ENSIP-16’s indexer + the introspection tech could form the foundation for such a meta-standard where clients can have a standardized way to discover and validate the underlying verification path.

Defining this spec for a minimal verifier interface in an ENSIP might be compelling.

—

@raffy

For ENS use-cases, a replay attack does not apply as Unruggable gateway is only used in read contexts.

Nice. So the attack surface falls back onto the verifier code and bridge contracts, not the gateways themselves, since the design is read-only and fetches verifiable data from external environments.

Is there any way for dApps to know which gateway and verifier were used during resolution? Having that metadata available could be valuable for debugging, trust signaling, and general DevSecOps visibility.

—

@raffy

The mainnet L2 primary name resolvers require a DAO vote and redeployment to change.

Oh, this is so important for delegates to understand! It’s a bit of a drag that a full DAO vote is required just to maintain operational resilience, though.

I believe @clowes.eth previously proposed a permissioned route, where the DAO could authorize ENS Labs with a streamlined path for deploying mission-critical updates (like gateway or verifier upgrades).

Perhaps this is something to explore further with @Meta-Gov_Stewards — whether there’s been any discussion around introducing a limited-scope “fast path” for verifier or gateway updates that could handle routine rollup or API changes without requiring a full DAO cycle, while still preserving immutability guarantees for the core logic.

—

@clowes.eth

What I originally envisioned (and still hope to see one day) with Unruggable Gateways is a decentralized network of versioned gateways with x/n matching response validation. dRPC are to an extent doing this, but there are still centralized entry points.

Oh, perhaps there’s room to design an economic coordination layer as a distributed threat-mitigation mechanism built on gateway consensus.

In this model, gateways that consistently return matching, timely proofs could earn attestations or rewards, while inconsistent or slow responders are penalized or gradually de-prioritized.

Over time, this could evolve ENS from relying on static, trusted gateways into a market of verifiable service providers, where correctness and reliability are reinforced through economic incentives.

—

@clowes.eth

I think that we should choose winners instead of spreading ourselves thin, and I think that more resources should be committed to the effort because it’s the core infrastructure for ENSv2.

I think it makes sense that ENS should verticalize its core gateway infrastructure in the short term to achieve stronger reliability guarantees and operational control.

Longer term, this could evolve into a market-based reliability layer, where gateways are economically incentivized to maintain high performance — shifting operational trust from control to incentive and verification.