202510291523 - ens-v2

Main Topic

Question: What is ENSv2, and what changes is it proposing compared to the current ENS protocol?

ENSv2 is a re-architecture of the Ethereum Name Service protocol aimed at making ENS work better in a multi-chain environment. The framing from ENS Labs is that new use cases and networks demand more flexibility: faster and cheaper operations, improved cross-chain resolution, and a more expressive ownership model.

Key ideas highlighted in ENSv2 material:

• Multi-chain resolution: one name should be usable across chains, with clearer cross-chain resolution behavior.
• Improved ownership model: ENSv2 proposes giving each .eth name its own registry, enabling finer-grained control over a namespace.
• New applications: ENS is splitting experiences into purpose-built products, including a consumer-facing ENS App and a developer-facing ENS Explorer.
• Namechain: ENS has discussed an upcoming L2 purpose-built for identity, positioned alongside ENSv2.

This is best understood as a protocol and product evolution at the same time: changing contract architecture while also changing the primary user interfaces.

🌲 Branching Questions

Q: What are ENS App and ENS Explorer, and why does ENS want two products?

ENS previously concentrated most functionality into a single manager experience. ENSv2 messaging argues that the user base has diversified: newcomers want simpler registration and identity management, while builders and power users want transparency and advanced controls.

ENS App is described as a streamlined consumer product centered on:

• registering names
• managing identity/profile
• reducing surface area and complexity

ENS Explorer is described as a developer tool focused on:

• visibility into protocol and ownership history
• advanced ownership capabilities
• custom resolvers
• detailed records useful for builders and integrators

The intent is specialization: keep the protocol neutral, but make the user experiences opinionated and optimized for different audiences.

Q: What does it mean that ENSv2 gives every .eth name its own registry, and what might that enable?

The phrase suggests shifting away from a single global registry model toward a per-name (per-namespace) registry model, where a name (like example.eth) can function more like a root of its own namespace with tailored control and potentially different policies.

Potential implications (high-level, based on the description rather than full contract specs):

• More flexible delegation and permissions within a namespace.
• Cleaner mental model for teams/companies that treat a name as an organizational root.
• Better composition with custom resolver logic or subname issuance policies.

Uncertainty: the exact capabilities depend on the final smart contract design. To be precise, this card needs the ENSv2 smart contract documentation and migration notes that define how registries are created, upgraded, and resolved.

References

• https://ens.domains/ensv2
• https://ens.domains/blog/post/ens-app-explorer-introduction
• https://ens.domains/blog/post/ensv2

References pending: ENSv2 smart contract specs and any formal EIPs / migration documentation.