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. 