ENS Solved the Wrong Half of the Naming Problem

ENS is a genuine improvement over DNS in one specific way: name ownership. When you register nick.eth, that ownership is secured by the Ethereum blockchain. No registrar can revoke it, no single organization controls the TLD, and no centralized authority can unilaterally transfer your name to someone else. That is a real property that DNS does not have.

The problem is that name ownership and namespace governance are two different things. ENS solved ownership. It did not solve governance.

Where the centralization moved

In DNS, authority over the namespace traces back to ICANN and the root zone. In ENS, it traces back to Ethereum Mainnet and the registry contract. The root has changed. The structure has not.

Every ENS name resolution starts on Ethereum L1. The ENS registry contract on Mainnet holds the authoritative mapping of names to resolver contracts. Before any name resolves to anything useful, the chain of authority has to pass through that contract. ENS's own documentation states this explicitly: "While ENS name resolution always starts from Ethereum Mainnet, it's possible to store almost all data associated with a name and its subdomains elsewhere."

Almost all data. Not the governance of the namespace. Not the authority over what a name means or how resolution works. That stays on Mainnet.

This is not a criticism of ENS's engineering choices. Anchoring authority to Ethereum Mainnet is what gives ENS its security guarantees. The tradeoff is deliberate. The point is that the tradeoff exists, and that it reproduces a structural dependency at a different layer than DNS, not a different kind of dependency.

Mutation governance is global by default. When an ENS name changes — resolver updated, record modified, ownership transferred — that change is a transaction on Ethereum Mainnet. It is subject to global finality. Every node in the Ethereum network eventually agrees on the new state. For name ownership, global finality is the right property. For cache coordination, routing policy, or namespace structure, it is expensive overhead with no structural benefit.

Structural adaptation is not governed locally. ENS supports subnames: if you own alice.eth, you can create pay.alice.eth and configure it as you wish. But the rules for how that subdomain resolves, how its resolver contract is structured, and how mutations to it propagate are not governed by the nodes responsible for that scope. They are governed by the Ethereum execution environment. The scope has no local policy. It has smart contract logic that anyone with the right key can call.

Offchain resolution introduces a different dependency. ENS's CCIP Read protocol allows resolution to defer to an offchain gateway when L1 data isn't sufficient. This is how subnames on L2 networks work: jesse.base.eth resolves by querying a gateway operated by Coinbase. The ENS docs acknowledge the trust assumption directly: in the trusted implementation, a malicious actor gaining control of the gateway can return false information. The namespace now depends on gateway operators in addition to L1 finality. The dependency didn't disappear; it forked.

What governed mutation would look like

The structural gap is not in ownership. It is in the layer that governs how the namespace evolves: how records change, how subnames are structured, how caches are coordinated, how structural changes propagate without requiring global finality for every mutation.

Governed mutation means: a proposed change to a name, a record, or a namespace scope is evaluated by the nodes responsible for that scope, under a policy local to that scope, and approved or rejected through scoped consensus. The change is recorded with a lineage that traces back through prior states. Resolution continues to work through the change because the lineage is preserved. No global finality required for the mutation itself.

This is architecturally distinct from what CCIP Read provides. CCIP Read moves data storage offchain. The resolution authority and the mutation governance model remain on L1. A governed namespace moves the policy itself: the rules for how a scope can change are held by the nodes governing that scope, not by a smart contract whose execution environment is global.

The practical difference is concrete. A namespace scope under regulatory pressure in one jurisdiction does not propagate that pressure to every other scope because its governance is local. A scope that grows beyond its current structure can split into child scopes without a global transaction. Cache coordination within a scope happens through local consensus, not through a resolver contract update on Mainnet.

The remaining gap in ENS

ENS is the most serious attempt to build a decentralized naming system at scale. The ownership model is sound. The CCIP Read extension shows that the ENS team understands the tradeoffs of keeping everything on L1 and is working around them pragmatically.

The remaining gap is in the governance layer. The namespace has no native mechanism for a scope to hold its own mutation policy, coordinate its own cache state, or make structural decisions about its own structure without routing authority through L1 or a trusted gateway. Those properties require a different assumption about where governance lives, not a more sophisticated implementation of the current assumption.

The architecture that provides those properties is an anchor-governed adaptive index: a hierarchical namespace where each scope is governed by the nodes responsible for it, mutations are validated through scoped consensus, resolution traverses the hierarchy stepwise through local anchor groups, and structural changes preserve lineage continuity without requiring global finality.