ENS names are fundamentally changing. ENSv2 replaces the single-object model with hierarchical registries that allow different parts of a namespace to branch into their own permissions, logic, and resolution systems.
Key changes:
- Names are no longer single entries with one owner and resolver
- Each name can now have its own registry and permission structure
- Different namespace segments can operate independently with custom logic
- The hierarchy becomes physically represented through the structure itself
This architectural shift makes ownership and delegation more expressive while ENS infrastructure handles the complexity. Names become structured systems built from linked parts rather than isolated setups.
The update maintains backward compatibility - existing subnames, CCIP-Read names, and imported DNS names continue working while gaining access to more powerful permissioning capabilities.
Is the Resolver changing? Yes. ENSv2 introduces a Universal Resolver: a single contract capable of resolving ENSv1, ENSv2, L2, and offchain names through CCIP-Read.
ENSv2 makes ownership and delegation more expressive under the hood, while ENS infrastructure abstracts away the complexity. Names are no longer single entries. They’re structured systems built from linked parts. Read more: ens.domains/blog/post/name…
ENS names can carry arbitrary records, making them the perfect vessel for an agent's full trust stack. One name holds everything: identity, discoverability, code integrity, capabilities. Query it and you get a score back: none, registered, discoverable, verified, full. That's
What’s actually changing with subnames in ENSv2? ENSv2 replaces the old flat registry model with a hierarchical registry system. Instead of everything living in one shared registry, each name gets its own registry and permission structure.
ENS names are no longer just single objects with one owner and one resolver. ENSv2 introduces hierarchical registries that let different parts of a namespace branch into their own permissions, logic, and resolution systems. Dive deeper: ens.domains/blog/post/name…
One of the biggest ENSv2 questions we’ve seen is about subnames. What happens to names like .base, .uni, imported DNS names, and CCIP-Read names? Here’s what changes, and what doesn’t 🧵
ENS is no longer a niche tool for crypto power users. Millions of names now exist across ecosystems, wallets, apps, and DNS integrations. ENSv2 is designed to support that kind of scale without losing the openness that made ENS useful in the first place.
Call registerAgentIdentity() and your agent gets a subname, an on-chain passport, and cryptographic proof linking to its owner. ENS is the anchor that makes it human-readable and resolvable. That's ENS as the entry point for agent identity.
ENSv2 replaces a flat registry with a hierarchy of linked registries, making ownership and delegation explicit onchain. Learn more: ens.domains/blog/post/name…
ENSv2 is coming, and with it, one big question: What happens to my name? Here’s everything you need to know about the upgrade 🧵
The tl;dr? ↪ Existing subnames keep working ↪ CCIP-Read names keep working ↪ Imported DNS names keep working ↪ ENSv2 introduces more powerful permissioning and delegation for subnames Keep an eye out for more FAQs on ENSv2!
ENSv2 is coming. A new foundation for names, built for integrations and subnames at scale. What will you build?
One of the most requested ENSv2 features is simpler payments. So can I buy ENS names with stablecoins? Yes. ENSv2 will support buying names with USD-denominated stablecoins (like USDC) from any EVM chain.
ENSv2 makes namespaces far more scalable. Instead of every ENS name maintaining its own isolated setup, registries can now be shared across many identities.
In ENSv2, the hierarchy becomes explicit. You open the eth vault and find every .eth name inside it. Open nick, and you can find sub nested within. The relationship between names is no longer implied. It is physically represented through the structure itself.
One thing became pretty clear this weekend: Agents need identity, discovery, permissions, reputation, coordination, and interoperable naming. A lot of builders reached for ENS to provide that foundation.
How will ENSv2 name pricing work? ENSv2 will make name pricing more predictable by setting registration and renewal costs in USD and supporting payment with stablecoins.
ENSv2 Launches Universal Resolver for Cross-Chain Name Resolution
**ENS is upgrading its resolver system with ENSv2** The Ethereum Name Service is introducing a Universal Resolver - a single smart contract that can resolve names across multiple environments: - ENSv1 names - ENSv2 names - Layer 2 networks - Offchain names via CCIP-Read **What developers need to know:** Applications using ENS should update their libraries to ensure compatibility with the new Universal Resolver. The system uses CCIP-Read protocol to fetch data from L2s and offchain sources. This consolidation simplifies the resolution process by eliminating the need for separate resolvers for different name types and networks. Developers can find implementation details in the [ENSv2 readiness documentation](https://docs.ens.domains/web/ensv2-readiness/). **Action required:** Review your ENS integration and update libraries to support cross-chain resolution.
ENS Launches registerAgentIdentity() for On-Chain Agent Verification

ENS has introduced `registerAgentIdentity()`, a new function that provides AI agents with on-chain identity infrastructure. When called, agents receive: - A human-readable ENS subname - An on-chain passport - Cryptographic proof linking the agent to its owner This builds on ENS's evolving role beyond simple name resolution. The system now supports: - **Arbitrary records** that carry an agent's full trust stack - **Identity scoring** (none, registered, discoverable, verified, full) - **Programmable resolvers** that execute logic like token swaps or privacy routing ENS serves as the accountability layer, transforming raw cryptographic keys into verifiable, human-readable identities. One ENS name can hold everything: identity, discoverability, code integrity, and capabilities. The infrastructure makes agents resolvable and accountable while maintaining the flexibility to chain complex actions through custom resolver logic.
🏆 Trust Resolution Layer Wins First Place for Verifiable Agent Identity
A **Trust Resolution Layer (TRL)** has taken first place for establishing verifiable AI agent identity through ENS. The system combines multiple components: - World ID verification - ENSIP-25 agent registration standard - ENSIP-26 context records - Novel AIP manifest system These elements work together to create a **progressive 5-tier trust scoring system** for autonomous agents. This infrastructure addresses a critical need as AI agents increasingly sign transactions, hold assets, and interact with blockchain protocols. The TRL builds on ENSIP-25, which introduced standardized verification that an onchain-registered AI agent is genuinely associated with an ENS name. The solution provides essential identity infrastructure for the growing ecosystem of autonomous agents operating in web3.
ENS Releases Alpha Log #5 with Reliability and Usability Updates

The Ethereum Name Service has published its fifth alpha development log for ENSv2, detailing continued improvements to the App and Explorer on the Sepolia testnet. **Key Updates:** - Focus on reliability, flexibility, and overall usability enhancements - Builds on previous fixes including transaction modal layouts and Fuses page improvements - Ongoing polish to search functionality, profiles, notifications, and name management features The ENSv2 testing phase continues on Sepolia as the team iterates on the user experience before mainnet deployment. More updates are expected in upcoming alpha logs.