ENSv2 Overview Lays Out Next-Generation Architecture for Ethereum Name Service

Last week I watched a friend send 400 USDC to 0x8f3a…c91e because the wallet in front of him refused to show a name.

Not because ENS went down. Because the reverse record had rotted.

That is the quiet failure nobody tweets about. And it is exactly the failure ENSv2 — the next-generation architecture the ENS docs published on October 12, 2026 — claims it will fix.

Hook

Ethereum's naming layer has run on one flat registry since 2017. ENSv2 replaces that single contract design with a hierarchical, tokenized system: every name becomes an ERC1155Singleton token in a Permissioned Registry, every account gets its own Permissioned Resolver instead of sharing one Public Resolver, and a single Universal Resolver V2 becomes the front door for all lookups.

The pitch is simple. The plumbing underneath is not.

Key Metrics at a Glance

Context: Why ENSv2 Exists

ENS started in 2017 as a flat mapping: name node → owner, resolver, TTL. That worked when nick.eth was a luxury. It strains now that ENS wants to be "the entire internet and beyond" — ENS Labs announced the ENSv2 roadmap on March 28, 2024, with goals of scaling beyond Ethereum mainnet into multichain environments.

The v1 design has three pressure points. First, one shared Public Resolver means every name's records live in one contract anyone can write to, with permission logic bolted on externally. Second, the flat registry cannot express subnames owned by their own sub-registries. Third, wrap/unwrap logic (the Name Wrapper and its fuses) became a compatibility layer everyone had to learn.

ENSv2's answer is to make names first-class tokens with built-in permissions, rather than layers stacked on one registry.

Core Content: What Actually Changes

The operations table in the ENS docs is the cleanest way to see the swap:

Three design choices deserve a hard look.

Fees move to stablecoins, grace shrinks to 28 days. The commit-reveal scheme survives, which is good — it stops front-running on premium names. But renewal fees in stablecoins plus a grace period cut from 90 days to 28 days changes the economics for anyone who has let a name lapse. The ENS DAO is already moving on this: executable proposal 6.43 ties revised .eth registration pricing to the v2 launch.

Resolvers go per-account. In ENSv1 most names shared one Public Resolver. In ENSv2 each account gets its own Permissioned Resolver, deployed through a shared Verifiable Factory. That factory is the trust anchor: the docs are explicit that the default setup deploys per-account resolvers and per-name subname registries through this single shared contract. If the factory has a bug, every new name inherits it. Follow the contract, not the blog post.

Reverse resolution is mirrored, not rebuilt. Primary names still work at launch because the Universal Resolver V2 mirrors existing v1 reverse records through ENSV1Resolver. The genuinely new L2 registrar and signature system is listed as "upcoming." So the multichain primary-name promise is a roadmap item, not a shipped feature.

Analysis: The Migration Is Where Users Get Hurt

Migration is two-phase. New registrations happen exclusively in ENSv2. Unmigrated names keep their v1 record-write paths, but renewals are routed through ETHRenewerV1, and wrapped-name fuses convert into ENSv2 roles along a defined migration path.

That split creates a window where the same name has two write paths. The docs themselves warn that until ENSv2 indexing is complete, "names migrated to ENSv2 appear with stale ownership" — meaning indexers and wallets may show the wrong owner for a migrated name.

That is not a cosmetic bug. Showing a stale owner is how a user sends funds to a name that has already changed hands.

ENSv2 Readiness Score (proprietary framework)

For app developers deciding when to wire in ENSv2, I score readiness on five weighted factors:

Readiness = (Resolver compatibility × 0.30) + (Migration support × 0.25) + (Indexing readiness × 0.20) + (Fee & grace handling × 0.15) + (Multichain reverse × 0.10)

A wallet that ships Universal Resolver V2 reads, handles dual write paths, and flags stale indexer data scores ~8/10. A wallet that only swapped the read path and ignored indexing scores ~4/10 — and that 4 is where users lose money.

What To Watch

Decision Framework

Building on ENS today?
├── Reads only → Use Universal Resolver V2 now (mirrors v1)
├── Writes for .eth names → New ETH Registrar; budget stablecoin fees, 28-day grace
├── Own subnames → register() on parent subregistry; do NOT build on Name Wrapper fuses
├── Unmigrated v1 names in your UI → keep v1 write paths; renewals go through ETHRenewerV1
├── Indexer/app → handle stale-ownership warning until ENSv2 indexing completes
└── Multichain primary names → wait for the L2 registrar/signature system

TL;DR

• What: ENS published the ENSv2 overview — a full architectural rewrite of the naming layer, announced 2024-03-28, docs live 2026-10-12
• Why: v1's flat registry and shared resolver don't scale to multichain; ENSv2 tokenizes names (ERC1155Singleton), gives per-account resolvers, and moves fees to stablecoins with a 28-day grace period
• Edge: Migration runs dual write paths; indexers can show stale owners for migrated names — the real user-harm window
• Watch: mainnet deploy, DAO proposals 6.43 and 5.22, Verifiable Factory audits, and the still-upcoming L2 reverse registrar

Sources

• ENSv2 Overview — ENS Docs
• ENSv2 Migration — ENS Docs
• ENSv2 Permissioned Registry / ERC1155Singleton — ENS Docs
• ENSv2 ETH Registrar — ENS Docs
• ENSv2 Reverse Resolution — ENS Docs
• ENSv2 Indexing — ENS Docs
• ENS Deployments (Sepolia/Mainnet ENSv2) — ENS Docs
• ENS DAO Proposal 6.43 (.eth pricing for v2)
• ENS DAO Proposal 5.22 (ENSv2 budget stream)
• ENSv2 announcement blog (March 28, 2024)

Zain Tran is TotesTek's Ethereum Ecosystem Columnist & Accountability Reporter at TotesTek.