ENS Research: Namechain, ENSIP-19 & Multichain Interop

🌱 ENS Ecosystem Community
1

Context

Kernel, a p2p research stoa for technical and civic inquiry, dialogue, and collaboration, hosted a “pop up” session on Namechain and Multichain Interoperability.

Builders convened to discuss ENSIP-19, the role of CCIP-Read in cross-chain resolution, ENSv2 and Namechain, and the open design questions around standards, event emissions, and secure migrations between L1 and L2.

tl;dr:

  • Mechanism + standard: CCIP-Read (EIP-3668) enables trust-minimized reads with proofs; ENSIP-19 standardizes multichain primary names for EVM chains.
  • Big trade-offs: interoperability standards vs. chain-specific freedom; migration finality windows; v1 renewal policy (keep unlocked on v1 vs. require migration)
  • What we need from you: views on auto-clearing L2 resolvers, v1 renewal policy, event/API standards for discoverability, and gateway/verifier requirements.

ENSv2: Raison d’être, a single name, everywhere.

ENS is a generic decentralized naming protocol, powered by the Ethereum blockchain. But it’s not just for Ethereum. Today, it already supports cross-chain forward resolution, and it is being designed to extend into other L1s and non-EVM environments. ENS also promises to bridge DNS—the de-facto read/write namespace of The Internet—directly into Ethereum, the canonical root of trust. In short, the aim is to collapse it into Ethereum’s root trust.

However, lifecycle management and primary name registration remain anchored to Mainnet.

To fulfill this promise, the ENS protocol must provide native, cost-effective lifecycle management and primary name resolution at scale. ENSv2 augurs well to deliver, offering low-cost registrations and renewals on Namechain, standardized multichain primary names via ENSIP-19, and trustless cross-chain resolution powered by CCIP-Read.

Limitations of ENSv1

Despite its broad adoption and flexibility, ENSv1 faces constraints that prevent it from fully realizing the vision of a single name, everywhere.

  • Mainnet dependency: Registrations, renewals, and transfers are tied to Mainnet, making ENS costly, as every transaction requires L1 gas.
  • Primary name limitations: While ENS supports forward resolution across chains, reverse resolution and primary names remain bound to Ethereum, preventing seamless multichain identity and limiting ENS’s potential as a universal identity layer.
  • Fragmented discoverability: The absence of standardized event and API emissions for subnames makes it difficult to enumerate and track names across environments, creating friction for tooling.
  • Migration risks: Moving names between mainnet and L2s introduces complexity. Without standardized mechanisms, users face risks of stale records, race conditions, and inconsistent states.
  • Incomplete integrations: DNS bridging exists but is not yet native or comprehensive. Similarly, non-EVM environments (e.g. email, app-specific namespaces, Web2 systems) lack a standardized framework for integration.

ENSv2 and Namechain are being designed to address these limits and carry the protocol toward its vision of a single, global namespace.

Questions called into discussion

How do CCIP-Read and ENSIP-19 serve as the mechanism and philosophy for extending ENS globally, and how does Ethereum’s role as the canonical root of trust get preserved as ENS scales across L2s, non-EVMs, and DNS?

CCIP-Read

EIP-3668 (also known as CCIP-Read) introduces a mechanism for Ethereum smart contracts to request and verify data from external systems via client-mediated lookups. With proper proofs, any external data source can behave as a verifiable extension of Ethereum’s trust model: metadata can be stored and accessed economically outside Ethereum, while resolution and verification remain trust-minimized on Mainnet.

The standard setup for making use of this mechanism is a gateway/verifier pair, reusable as a plug-in for new environments — making the model tractable, repeatable, and scalable. This is the linchpin driving ENS strategy for global adoption.

ENSIP-19

ENSIP-19, standardizes reverse and primary name resolution across EVM chains and coin types (per ENSIP-9/11). In practice, it extends ENS beyond Mainnet, giving wallets, dapps, and other Ethereum environments a chain-aware, standardized way to display a user’s name across networks. ENSIP-19 alone doesn’t mandate CCIP-Read; it is scoped specifically to Ethereum-family chains and addresses. CCIP-Read, meanwhile, generalizes resolution to arbitrary external data sources, providing the transport layer that makes trustless cross-chain resolution viable.

The Caveat

Together, ENSIP-19 provides the standard and CCIP-Read provides the mechanism: primary-name data registered on other EVM chains can be proven back to Ethereum during resolution. There’s a limitation: ENSIP-19 only defines the resolution standard for EVM-family chains and coin types; non-EVM systems such as Solana, Bitcoin, or DNS remain outside its scope. New standards will be defined that leverage CCIP-read’s functionalities, specifying how proofs are generated, verified on Ethereum, and mapped to ENS records.

Scaling with the Trust Model

This model anchors Ethereum Mainnet as the canonical root of trust while enabling Namechain and other L2s to handle economic, scalable lifecycle operations. 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.

This architecture preserves Ethereum’s security guarantees while enabling ENS to expand into new environments. By rooting trust on mainnet and extending resolution outward through CCIP-Read, ENS can scale cost-effectively and interoperably, moving closer to its vision of a single, global identity layer for the internet.

What are the trade-offs between flexible, chain-specific implementations and common interoperability, and what steps are needed to ensure usernames remain valid, discoverable and interoperable across ecosystems?

The Trade-off

Chain-specific implementations enable ecosystems to tailor ENS integrations to their own needs and specifications. This lowers the barrier for experimentation and lets new environments move quickly. The trade-off is fragmentation: without shared standards, usernames may work locally but fail to interoperate with wallets, explorers, or other ENS-aware tooling across the ecosystem.

The Necessity of Interoperability

Interoperability ensures that usernames remain enumerable, discoverable, and portable across EVM family chains and non-EVM environments. For example, if an L2 or app-specific registry doesn’t emit standardized events, the names still “exist” but won’t be visible to tools like ENS Node or widely supported by wallets. They risk becoming siloed namespaces rather than part of the global ENS ecosystem. This is the core tension: too much flexibility undermines the promise of a single, coherent namespace.

Standards in Development

ENS aims to make it simple for new environments (L2s, L1s, non-EVM like DNS) to plug in by using standardized resolver/registry contracts and event schemas, rather than forcing each ecosystem to engineer its own bespoke integration.

Work on this is already underway, while other initiatives remain on queue:

  • Standard contracts (in progress): ENS is building resolver and registry contracts for EVM chains (e.g., L2s like base.eth) to shift record storage and resolution off Mainnet with minimal configuration. For non-EVM environments (DNS, Solana, Bitcoin, etc.), CCIP-Read provides the mechanism, but additional standards for proofs and verifiers will need to be defined.
  • Event standards (drafts underway): Draft standards are underway for L2 registries and resolvers to emit uniform events (e.g., subname creation, transfer, burn), ensuring names are enumerable and indexable by ENS tooling.
  • Integration playbook (planned, pending Namechain): ENS intends to provide comprehensive documentation that outlines the exact steps for an L2 or ecosystem to add primary names — from gateway/verifier setup to event emissions. This reduces bespoke engineering and promotes alignment. This is likely to come after the launch of Namechain, since current focus is on core protocol delivery.

How should ENS handle latency and finality challenges during L1↔L2 migrations — particularly the open design choice of whether to auto-clear L2 resolvers after ejection?

Latency and Finality Challenges in L1 ↔ L2 Migrations

Although users can temporarily choose to remain on L1 or migrate to Namechain, the long-term direction of ENSv2 is to move lifecycle operations (registrations, renewals, transfers) to Namechain by default, with L1 serving as an opt-out path for those who prioritize maximum security.

When names move between these environments, control of the name has to shift from one chain to the other. Because blockchains finalize transactions at different speeds, there are always latency and finality windows — intermittent periods where one chain has not yet updated its state while the other has already acted on it.

This shift therefore introduces design trade-offs that balance short-term flexibility for users against the integrity and simplicity of the system overall.

Why migrations happen.

In ENSv2, most names will live on Namechain by default, but users who want maximum security or independence from L2 finality can ‘eject’ a name back to Mainnet. Ejection moves the authoritative control of the name from L2 to L1.

What are stale records and why they matter.

When a user ‘ejects’ to L1 from L2 (Namechain), the old resolver on L2 doesn’t automatically disappear. Unless it’s explicitly cleared, it may continue serving the last-known records even though the name is no longer controlled there. This creates the possibility of stale data being returned if a client, cache, or indexer queries L2 directly or doesn’t follow the L1-first resolution flow.

Nick described this as an open design choice: ENS must weigh consistency and cleanliness (auto-clearing) against availability and convenience (not auto-clearing), and explicitly invited community input before deciding:

  • With auto-clearing: The L2 resolver is zeroed out or disabled as soon as the name is ejected. This guarantees consistency and prevents stale data from being read, but it introduces a temporary outage until the L1 activation finalizes, and adds overhead from extra cross-chain messaging.
  • Without auto-clearing: The L2 resolver is left as-is, meaning clients or misconfigured tools might still query it and return stale records even though the name has moved back to L1. This avoids outages during migration and preserves backwards compatibility, but creates the risk of inconsistent resolution.

Additional latency in the reverse case.

When migrating a name back from L1 to L2, Mainnet burns the record immediately while L2 activation finalizes later, creating a brief, unavoidable outage window—independent of any resolver-clearing policy.

This is an inherent latency/finality limitation that ENS intends to mitigate via clear client guidance and status signaling, not eliminate.

For v1 renewals, should ENS allow unlocked names to renew indefinitely, or require migration before any renewal for consistency?

The Name Wrapper Contract

The Name Wrapper allows any ENS name — be it a 2LD .eth, 3LD.eth, or even a DNS-imported name — to be “wrapped” into an ERC-1155 NFT. In practice, this means the ownership of the name is transferred to the Wrapper contract, and the user receives a corresponding NFT, representing ownership of that name.

Like other NFTs, the wrapped name can be transferred, traded, or managed through standard ERC-1155 mechanics. Wrapping simplifies the permission model by consolidating roles: the Wrapper contract holds ownership in the ENS registry, while the user’s NFT represents full control in an account.

Where the Name Wrapper becomes especially powerful is in its fuse system. Fuses function like a permissions set that allow fine-grained control over how owners or parents can manage names. This flexibility in administration enables use cases like permanently locked subdomains for communities or unruggable namespaces where neither parents nor intermediaries can interfere once a name is issued.

What Changes in ENSv2

The v1 registrar controller currently allows both unlocked and locked (wrapped) names to be renewed on ENSv1. Once it is revoked with the introduction of ENSv2, this behavior diverges:

  • Unlocked names may continue to be renewed indefinitely on v1, unless ENS governance decides otherwise.
  • Locked names, however, rely on the wrapper’s internal expiry and the registrar controller to extend it. Once the v1 controller is revoked, these names can no longer be renewed in v1 and will eventually expire unless migrated to ENSv2.

This revocation introduces an inconsistency between unlocked and locked names, creating the conditions for a two-class system within the namespace. It is this divergence that makes the question of v1 renewals an open design decision for ENS governance.

Why Renewals Become a Design Problem

Remember, once the v1 registrar controller is revoked, locked names will no longer be renewable — meaning they will eventually expire unless migrated to Namechain. Unlocked names, however, could still be renewed indefinitely on v1 if ENS allows it.

This creates a policy dilemma. ENS can:

  • Allow renewals of unlocked v1 names, preserving flexibility for users who don’t want to migrate immediately. But locked names would still expire, resulting in a two-class system and adding long-term complexity.
  • Require migration before any renewal, ensuring all names follow the same rules and avoiding fragmentation. But this removes backwards compatibility and forces users to migrate sooner.

The former allows the majority of v1 names (unlocked) to be preserved indefinitely without migration, preserving user sovereignty. The latter maintains simplicity and treats all users identically, eventually forcing users to migrate to Namechain to continue renewals . The risk is creating a fragmented namespace with layers of special-case logic. The choice between these options remains undecided, and input from the community is welcome.

In both the v1 renewal debate and the resolver migration decision, the same tension emerges: short-term flexibility versus long-term coherence.

Beyond audits, what safeguards are needed to strengthen ENS security — especially against UX risks like address poisoning?

Addressing Security Challenges

User-friendly names already mitigate many of the worst UX problems around address poisoning, where malicious actors seed a victim’s wallet history with lookalike or fake addresses in the hope the victim falls prey. With ENS, users have guardrails: they interact with human-readable names instead of raw alphanumeric hexadecimal strings, reducing the chance of copying an attacker’s address.

However, this is not a silver bullet. Wallets and apps still need to play their part in protecting users. The discussion highlighted two safeguards that could be put into practice and would meaningfully reduce UX risk:

  • Address books and interaction memory: Wallets should store and surface context around past interactions (e.g., “you’ve sent funds to this ENS name before”). This provides continuity and helps users spot anomalies.
  • Warnings on new or first-time interactions: Highlighting that a user is about to transact with a new address or ENS name gives them the opportunity to double-check, rather than blindly trusting history.

Audits and Formal Proofs for ENSv2

On the protocol side, ENSv2 is already undergoing two independent audits, which is standard practice for high-stakes smart contracts. But importantly, one of these teams is also developing formal proofs of core properties — mathematically verifying that critical invariants (e.g., “only the rightful controller can update a name”) hold under all possible execution paths. This dual approach improves confidence in ENSv2’s correctness and reliability upon release.

Open Questions for Further Research

As demonstrated, the majority of concerns rest on governance, design trade-offs, and adoption efforts. The discussion aims to stimulate further inquiry from the community and foster a research-first approach. Accordingly, we propose the following questions for deeper exploration:

Protocol design and specifications

  • How should ENS reconcile ENSIP-19 with existing chain-ID standards (CAIP-2, chainlist, SLIP-44, etc.) to avoid fragmentation?
  • What’s the minimal common verifier interface across L2s and non-EVM chains, and how do proof sizes, gas costs, and finality windows compare?
  • Should resolvers forbid multi-hop CCIP-Read lookups, or allow them with caps/timeouts?
  • What’s the minimal event/API standard that ensures reliable subname discovery across chains?
  • Does ENS need a canonicalization mechanism (like a CNAME-for-ENS) for unifying app-issued names or aliases?

Security and reliability

  • What should the threat model for ENSv2 look like (gateway compromise, verifier bugs, replay/out-of-finality reads)?
  • How should we quantify and mitigate finality windows during migrations?
  • What operational standards (SLA, key management, attestation) should gateways and verifiers meet?

Identity and semantics

  • Should ENS support email semantics (IDNA mapping, punycode-like transforms, new label types), and how do we balance phishing risks with usability gains?
  • What proof formats or gateways can enable reverse resolution for non-EVM chains like Solana or Bitcoin?

With appreciation to the Ecosystem stewards for convening these conversations, I’d love focused feedback on what felt most urgent to explore:

  • Auto-clearing after ejection (consistency vs availability)
  • v1 renewal policy (indefinite for unlocked vs migrate-before-renew)
  • Minimal discoverability event/API set for subnames
  • Gateway/verifier expectations (SLA, attestations, audits)

Disclosure: I’m not technical-first, just puzzle-obsessed (ENS is the second-biggest puzzle after Ethereum!). This is a clarion call: bring the giga-brain takes here and in the Ecosystem WG calls. If there are concrete proposals (interface snippets, event schemas, verifier requirements, wallet UX patterns), please share.

Thanks to all who joined the pop-up and to ENS builders for pushing this work forward. :pray:

4 Likes
2

This post made me so happy. Thank you @estmcmxci – you touched on all the important points.

Echoing the importance of this research, because we’re facing these exact challenges right now.

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.

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).

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.

Right now, we’re unsure how to proceed. The technical lift is too heavy for us to take on individually for each chain, and developing a universal standard from scratch would require significant R&D work first.

That said, we’d love to collaborate and contribute (in a limited capacity this term) alongside whoever is leading the initiative and the teams already involved.

3 Likes
3

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.

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

  • ICompositeExtendedResolver – this builds upon IExtendedResolver and allows a resolver to expose “underlying” resolvers. This is useful for “eth” (ETHTLDResolver → “eth” itself, Mainnet V1, and Namechain V2 via Unruggable) and various DNS TLDs (DNSTLDResolver → gasless DNSSEC resolver) since those resolvers function like routers.
  • IVerifiableResolver – this exposes the underlying destination of a crosschain resolver. However, it’s limitation is that it one-per-resolver verifier and gateways of a resolver.

There also is the new ENSIP-16 interface, which exposes an indexer for efficient offchain and crosschain accessibility and coinType/chainId.

Proofs that use non-native hash functions are expensive (eg. Blake, Poseidon, Pederson, etc.)

Finality windows are specific to each rollup design. Optimistic chains like Base and Arbitrum use a “delayed-but-prefinalized” state since full finalization is too slow. The OPFaultVerifier design was recently audited by Coinbase and Unruggable added some improved mitigations. There also have been some experiments regarding “trusting the sequencer” for incredibly fast (~minutes) crosschain access. Namechain will have fast finality.

The Unruggable design is powerful enough that a single CCIP-Read is sufficient for any request that fits within the gas limit (mostly consumed by proof verification on the callback.) The most sophisticated examples are the new ETHTLDResolver and Unruggable Layer-3 verifiers (eg. Ape chain).

The original ETHTLDResolver design would do recursive CCIP-Read if a multicall was “too large” (aka automatic paging) but we changed this to a more elegant one, where the Unruggable gateway itself can tell the Unruggable verifier that the request is too large to prove. Clients can intercept this error and break a large request up into chunks.

In ENSv2, with the new DedicatedResolver design, the same resolver can be mounted under multiple names, which enables aliased records. This also implies that you can swap between multiple resolvers without destroying your old data (re: opposed to PublicResolver versioning). With indexing, it’s possible to find all of the names with a specific resolver set.

You can also alias at the registry level, which would clone an entire namespace (subtree).

Gateways aren’t trusted, anyone can run one. The only “trust” is in which URLs are used when a resolution occurs. I have a proof-of-concept tool for this called CCIPRewriter which allows you to hijack any CCIP-Read gateway and replace it with your own in any application which uses ENS (eg. for privacy, speed, whatever.)

Gateway request responses have liveliness guards which are anchored to each rollup contract.

Verifiers certainly could have bugs but have been audited. Most verification functions use external audited code, like the official Optimism repo, which is the same code used for bridge withdrawals.

Rollups certainly could have bugs, but the bridge contract would be the primary target.

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

The general task of upgrading a gateway when a change is required (eg. an api-breaking rollup upgrade) has not been solved. The mainnet L2 primary name resolvers require a DAO vote and redeployment to change. The verifiers have owners only to tweak the default gateway URLs, which can be supplied by the user of the verifier. The rest of the stack is ownerless and immuable. There is no fast path to fix a verifier in ENSv1.

A compromised gateway + a functioning rollup will only error. There’s no middle ground. It either can supply valid proofs or it can’t. The primary issue with gateways is RPC latency and uptime, which mostly hinges on the various quirks in L2 *_getProof functions which are rarely used by nearly all RPC consumers.

Beyond bugs mentioned above, the optimistic rollup attack vector is commiting an invalid state proof through the rollup machinery that isn’t caught within the 6-hr delay period. Arb is bonded at 3600 ETH. I believe Base and OP have whitelisted proposers and the recent Coinbase audit (mentioned above) adds an additional filter for this. The operating assumption is fast bridges and crosschain arbers will catch this (a proposed state root that doesn’t match the source chain) almost immediately.

2 Likes
4

This is a valid point. The issue that ENS has is that specifications such as ENSIP-11 require an intimate knowledge of historical chain identification methodologies. The complexities and inconsistencies are a barrier to entry for developers.

My gut reaction is using an ERC-7930 Interoperable Address as the label for reverse namespaces, as well as for multi chain address resolution more generally. We will be sharing more on our work on ERC-7930 shortly. Any changes to multichain resolution standards need to be carefully considered and Forward Compatible.

No. Never say never, but I havn’t seen anyone do this and I can’t think of many use-cases that would require more than two hops. If they do, I’d argue that the resolver should be architected differently.

@raffy has outlined some of the patterns and features within Unruggable Gateways that allow for efficient data resolution.

This is a real issue, and one that we have seen in practice. In terms of the Unruggable Gateway piece of the puzzle, we work closely with rollup teams to mitigate and… well… we learn from experience. This is novel tech, we iterate and learn - that’s what makes it fun to work on.

The Base team have been fantastic in this regard - they have talented engineers, communicate openly, and proactively engage to help improve the solution. As @raffy mentioned, Alexis at Coinbase did an impromptu audit of the code relating to the OP stack (on which Base runs), and it yielded valuable improvements to the codebase.

Anyone can run one, and people/teams should run one/many. We’ve built tooling to make it super simple to deploy and operate Unruggable Gateways with very minimal technical knowledge. More to follow - limited hours in the day.

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.

I’m curious as to what kind of attack vectors people envision being plausible were a verifier to return a false positive?

The problem is that Unruggable Gateways have external dependencies. No sane operator is going to provide uptime guarantees unless they bring everything in-house and can control their own destiny. The legitimacy and uptake of solutions that build on top of this tech (ENS for example) is dependent on this.

Candidly, no RPC provider is currently 100% reliable for the Unruggable Gateways use case. Our operational gateways do occasionally go down because RPC operators opaquely change their configuration settings without notice.

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.

2 Likes
5

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:

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.

—

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.

—

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.”

—

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.

—

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.

—

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.

—

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.

—

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.

—

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.

1 Like
6

Can you expand on what you mean here? EVM Gateway / Unruggable Gateway provides a standard interface for verifiers, of which one implementation per L2 is required. If multiple L2s share the same codebase, they can use the same verifier implementation. Is that not what you’re looking for?

7

Sure thing. As @cap noted earlier, new L1s and ecosystems continue to emerge (app chains, for instance), each with distinct consensus mechanisms, proof systems, and runtime environments.

Non-EVM networks such as Solana, Aptos, and Near use fundamentally different consensus models, state representations, and proof mechanisms that are not directly compatible with Ethereum’s proof verification.

The Unruggable Gateway, while a major innovation, remains limited to proof formats and verification logic from EVM-based rollups. There is currently no standard method for verifying non-EVM chain state on Ethereum L1.

If we want Ethereum to succeed in its pursuit of becoming the canonical root of trust, ENS can support this mission by extending onchain resolution to non-EVM environments.

To achieve this, a minimal verifier interface that supports multichain and cross-environment resolution would allow each chain to implement its own proof verification logic while enabling ENS and gateways to interact with them through a common, standardized schema.

8

Unruggable Gateway is one implementation of CCIP-Read, which provides a generic means of fetching and verifying offchain data. This same mechanism can be used for any offchain name resolution - and in fact already is. Two prominent examples include gasless DNS, which uses CCIP-Read to resolve DNS records and validate them via DNSSEC, and offchain resolution of names such as those used by coinbase, which rely on verifying signed records returned by their API.

9

→ For DNS, the verifier (validator) is the DNSSEC oracle.
→ For rollups, it’s the Unruggable Gateway.

CCIP-read is the transport layer, while the above mentioned are verification methods. CCIP-read can be extended to support exogenous proof systems (.ie custom onchain verifiers for non-EVM chains).

But do we need a new implementation for each individual proof system? Or can we develop a common interface that supports this, like a universal socket?

—

Harking back to this point, is this a trend or fad? Do we see app chains adopting namespace systems?

—

Curious whether it’s worth further inquiry on both fronts.