Ethereum Name Service (ENS)

Ethereum Name Service: The Registry, Resolvers, and DAO Behind .eth Names

ENS turns blockchain addresses and other records into human-readable names, but its practical value depends on registrars, resolvers, wallet support, renewal rules, and DAO-controlled upgrades.

What ENS actually provides

Ethereum Name Service is a naming protocol built on Ethereum. It maps names such as alice.eth to machine-readable records, including Ethereum addresses, other cryptocurrency addresses, content hashes, text metadata, and reverse names associated with wallet addresses. The system is broader than a wallet-labeling tool: applications can use ENS records to discover addresses, websites, decentralized content, and profile information without requiring users to work directly with hexadecimal identifiers.

ENS also supports names outside the native .eth namespace through DNS integrations. The project documentation describes importing DNS names with DNSSEC, which creates a dependency on the rules and security assumptions of the relevant DNS infrastructure. That makes ENS useful as a naming layer, but not fully independent of existing internet naming systems in every use case.

How the architecture fits together

The registry is the central lookup contract. It records each domain’s owner, resolver, and time-to-live value, and applications begin resolution by querying it. Registrars control how names under a top-level domain are allocated; the .eth registrar handles .eth names, while separate mechanisms exist for reverse records and DNS names. Resolvers then expose the actual records associated with a name, such as an address, content hash, or text field.

The contract repository shows the modular design in more detail. It includes registry contracts, the ETH registrar, reverse resolution, bulk renewal, pricing oracles, and public resolver profiles for address, content-hash, text, ABI, public-key, and reverse-name records. This separation allows different components to be upgraded or replaced under their own control paths, but it also means users depend on several contracts and interfaces rather than one isolated application.

Registration, renewal, and subnames

Traditional .eth registration uses a commit-reveal process. A user first submits a commitment containing the intended name and a secret, waits through the required delay, and then reveals the registration parameters. The mechanism is designed to reduce front-running during name registration. Any account may renew a name by paying the applicable fee, so renewal rights and name ownership are separate concepts.

ENS’s Name Wrapper adds structured control over subnames. Wrapped names can carry expiry information and “fuses,” which are restrictions that a parent can burn to limit future changes to a subname. The parent name’s expiry constrains the maximum expiry of its subnames, creating a hierarchy in which subname rights depend on the parent’s continuing control and validity. This is useful for organizations and applications that want to issue managed names, but it introduces additional permission and expiry logic that integrators must handle correctly.

ENSv2 is a material dependency

The current ENS documentation describes ENSv2 as a redesign of the registration and resolution architecture. Its proposed ETH Registrar retains commit-reveal registration while adding features such as multi-year discounts, ERC-20 payment support, a Permissioned Registry, and more granular access-control roles. The documentation explicitly says that the contracts and interfaces are not yet final and may change before mainnet deployment. That makes ENSv2 relevant to the project’s direction, but not appropriate to present as a settled production guarantee without checking deployment status and migration instructions.

The proposed design also changes several user-facing assumptions, including the post-expiry grace period, the representation of name ownership, and the roles granted at registration. Applications that integrate directly with ENS contracts may therefore need to distinguish between ENSv1 behavior and ENSv2 deployments rather than assuming that one contract model applies everywhere.

What the ENS token controls

ENS is an ERC-20 governance token rather than the name record itself. ENS documentation describes the token as the voting-weight mechanism for the ENS DAO and identifies the Ethereum token contract as the official governance token. Name ownership, registration, renewal, and resolution are handled by the protocol’s registrars, registry, resolver, and wrapper contracts. The token’s direct role is therefore governance influence, not ownership of an .eth name.

The DAO’s process combines forum discussion, off-chain signaling, delegation, and binding on-chain proposals. The governance documentation states that executable proposals require at least 100,000 delegated ENS to submit, followed by a seven-day voting period and a two-day timelock if approved. Executable proposals can move treasury assets, alter governance contracts, or perform other on-chain actions. This gives token holders meaningful control, but it also makes delegation concentration, voter participation, and proposal review important practical dependencies.

Users, dependencies, and limits

ENS is intended for wallet users, decentralized applications, developers, organizations, and services that need readable identifiers or structured metadata. Its usefulness depends on wallets and applications resolving names correctly, displaying the right records, and warning users when a name is expired, misconfigured, or visually deceptive. Ethereum’s developer documentation presents ENS naming as a way to reduce reliance on opaque contract addresses, but readable names do not by themselves prove that a recipient or application is trustworthy.

The DAO constitution places limits on how governance may treat name owners, including a stated protection against infringing ownership rights or selectively changing costs for individual names. These rules provide a governance framework, not an unconditional technical guarantee. The registry, registrar, resolver, wrapper, root controls, and future ENSv2 components remain separate surfaces whose permissions and deployment status must be evaluated when assessing a specific integration.

Key takeaways

• ENS is a naming and records protocol, not merely a marketplace for .eth domains.
• The registry stores ownership and resolver pointers; registrars allocate names and resolvers expose their records.
• Name Wrapper features such as subname expiry and fuses support managed hierarchies but add permission complexity.
• ENS is primarily a governance token: the DAO can influence treasury, governance, and certain protocol actions through proposals.
• ENSv2 documentation describes a significant architectural transition whose contracts and interfaces are expressly not final.

Risks and open questions

• ENSv2 contracts and interfaces may change before mainnet deployment, creating migration and integration risk.
• Users may mistake a readable ENS name for proof of identity or transaction safety; names can be spoofed, misconfigured, expired, or assigned misleading records.
• Resolution depends on multiple contracts, wallet integrations, registrars, resolvers, and root or DAO-controlled components.
• Subname permissions, expiry inheritance, and burned fuses can create irreversible or difficult-to-repair administrative states.
• DAO outcomes depend on delegated voting power, participation, proposal review, and the authority granted to executable proposals.