How ENS (Ethereum Name Service) Works

The Ethereum Name Service (ENS) is a decentralized naming system built on the Ethereum blockchain that maps human-readable names like vitalik.eth to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, and arbitrary metadata. If DNS is the phone book of the traditional internet, ENS is its blockchain-native counterpart — a permissionless, censorship-resistant directory that no single entity controls. Unlike conventional top-level domains managed through ICANN's hierarchy, .eth names exist as NFTs (ERC-721 tokens) on Ethereum, meaning you truly own your name rather than renting it from a registrar.

ENS is the most widely adopted blockchain domain system, with millions of registered names and deep integration across wallets, dApps, and browsers. Understanding its architecture reveals a system that is simultaneously simpler and more flexible than DNS, built from three core contract layers: the registry, resolvers, and the registrar.

ENS Architecture: Registry, Resolvers, and Registrar

ENS is not a single smart contract but a system of interacting contracts, each with a focused responsibility. This separation of concerns is a deliberate design choice that allows individual components to be upgraded without disrupting the entire system.

The Registry

The ENS Registry is the core contract and is deliberately minimal. It stores just three pieces of information for each name (identified by a namehash — more on this below): the owner of the name, the resolver contract that holds the name's records, and a TTL (time-to-live) value. The registry does not store addresses, text records, or any other data. It is purely a directory that maps names to their owners and resolvers.

The owner of a name can transfer ownership, set the resolver, create subdomains, and delegate control. Ownership is enforced entirely on-chain — no registrar, corporation, or government can seize a name from its owner without access to the controlling Ethereum account (or governance action by the ENS DAO for the root node, discussed later).

Resolvers

A resolver is a separate smart contract that stores the actual records for a name: Ethereum addresses, other cryptocurrency addresses, content hashes, text key-value pairs, ABI definitions, and more. When a client wants to look up the address for vitalik.eth, it first asks the registry "which resolver handles this name?" and then asks that resolver "what is the ETH address for this name?"

This two-step resolution process is what makes ENS extensible. Anyone can deploy a new resolver contract that supports new record types without modifying the registry. The Public Resolver is the default resolver contract provided by ENS, and it supports all standardized record types. But name owners can point to custom resolvers with arbitrary logic — for example, a resolver that returns different addresses based on the time of day, or one that reads data from a Layer 2 chain.

The .eth Registrar

The registrar manages the registration and renewal of second-level .eth names (like example.eth). It is the owner of the eth node in the registry, and when you register a name, the registrar sets you as the owner of that name's node. The current registrar is the ETHRegistrarController, which handles pricing, name validation, and the commit-reveal registration process.

The registrar is distinct from the registry because it encodes policy — how much names cost, how long they can be registered for, what characters are allowed — while the registry is policy-free. This separation means the registration rules can be updated (through ENS DAO governance) without touching the core name resolution infrastructure.

Namehash: How Names Become Identifiers

ENS does not store names as strings on-chain. Instead, it uses a deterministic hashing algorithm called namehash to convert any name into a fixed-length 256-bit identifier (a bytes32 value). The algorithm works recursively from right to left:

1. The namehash of the empty string (the root) is 32 zero bytes: 0x0000...0000
2. For any other name, namehash("label.remainder") = keccak256(namehash("remainder") + keccak256("label"))

So for vitalik.eth:

namehash("")          = 0x0000...0000
namehash("eth")       = keccak256(namehash("") + keccak256("eth"))
namehash("vitalik.eth") = keccak256(namehash("eth") + keccak256("vitalik"))

This scheme has an important property: a parent name's hash is not derivable from a child's hash, and you cannot reverse a namehash back to its original name without already knowing the name. The registry only stores namehashes, which means the on-chain data does not reveal what names exist (although the registration transactions themselves do). Namehash also means the registry is flat — it does not need to understand dots or hierarchical structure. All hierarchy is encoded in the hash computation.

.eth Domain Registration and Renewal

Registering a .eth name is a two-step process designed to prevent front-running:

1. Commit — You submit a hash of (name + owner + secret) to the registrar. This commits you to a specific name without revealing which name you want. The commit must age for at least one minute (to ensure it's included in a block before the reveal).
2. Register — After the commit has aged (but within 24 hours), you submit the actual registration transaction, revealing the name, owner, and secret. The registrar verifies the commit matches, charges the registration fee, and sets you as the owner in the registry.

Without this commit-reveal scheme, a malicious miner (or MEV bot) could see your registration transaction in the mempool, front-run it to register the name first, and then sell it back to you at a premium.

Pricing

ENS name pricing is based on character length, with shorter names being more expensive because they are more scarce and desirable:

• 5+ characters — $5/year
• 4 characters — $160/year
• 3 characters — $640/year

One- and two-character names have been released through separate processes. Registration fees are paid in ETH (the contract uses a Chainlink price oracle to convert from USD pricing). All registration revenue goes to the ENS DAO treasury.

Renewal and Expiration

ENS names are registered for a finite period (minimum one year) and must be renewed. After a name expires, there is a 90-day grace period during which the original owner can still renew. After the grace period, the name enters a 21-day premium auction where the price starts at $100 million and decays exponentially to the standard rate. This Dutch auction mechanism prevents sniping of recently expired valuable names.

Name owners can renew at any time, extending the registration period by additional years. Anyone can renew a name on behalf of its owner — you do not need to be the owner to pay renewal fees, which enables third-party services and gifting.

Name Resolution: The Full Flow

When a wallet or dApp needs to resolve alice.eth to an Ethereum address, the following steps occur:

In modern ENS usage, most clients call the Universal Resolver contract rather than interacting with the registry and resolver directly. The Universal Resolver handles the full resolution pipeline in a single call, including support for CCIP-Read (offchain resolution), wildcard resolution, and fallback logic. This simplifies client implementations enormously — a wallet only needs to call one contract.

Under the hood, the process is: compute the namehash for alice.eth, query the registry for the resolver address, then call the appropriate function on that resolver (addr() for Ethereum addresses, text() for text records, contenthash() for content hashes, etc.). All of this happens through standard Ethereum RPC calls, meaning any Ethereum node can resolve ENS names.

Reverse Resolution

Forward resolution maps a name to an address: alice.eth → 0xabc...def. Reverse resolution does the opposite: given an Ethereum address, it returns the associated ENS name. This is what allows wallets and block explorers to show vitalik.eth instead of 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045.

Reverse resolution works through a special-purpose namespace: .addr.reverse. When a user claims their reverse record, they set the name associated with their address at the node <address>.addr.reverse. For example, the reverse record for 0xabc...def is stored at the namehash of abc...def.addr.reverse.

The reverse registrar enforces that only the owner of an address can set its reverse record, preventing anyone from claiming to be vitalik.eth without controlling the corresponding address. Applications should always verify that the forward resolution of the claimed name matches the address in question — a name that reverse-resolves to alice.eth is only valid if alice.eth forward-resolves back to that same address. This bidirectional check prevents spoofing.

Text Records: Avatar, Email, URL, and More

Beyond addresses, ENS resolvers store arbitrary text records — key-value pairs that turn an ENS name into a decentralized profile. The resolver's text(node, key) function returns a string value for any key. While keys are arbitrary strings, a set of global keys has been standardized:

• avatar — A URL or NFT reference for the user's profile image. Supports HTTPS URLs, IPFS URIs (ipfs://Qm...), and NFT references (eip155:1/erc721:0xBC4CA.../1234 for a specific Bored Ape, for example). Wallets and dApps render these as profile pictures.
• email — An email address.
• url — A website URL.
• description — A bio or description.
• com.twitter — A Twitter/X handle.
• com.github — A GitHub username.
• com.discord — A Discord username.
• notice — A short notice or status message.
• keywords — Comma-separated keywords describing the entity.

Service-specific keys use the reverse domain notation (e.g., com.twitter rather than twitter) to prevent namespace collisions. Any application can define and read custom keys without requiring protocol changes, making text records an infinitely extensible profile system. This is analogous to DNS TXT records, which similarly store arbitrary text data and are used for email authentication (SPF, DKIM), domain verification, and other purposes.

Content Hash Records: IPFS and Swarm Hosting

One of ENS's most powerful features is the content hash record, which maps a name to decentralized web content. By setting a content hash, you can make yourname.eth resolve to a website hosted on IPFS, Swarm, or other content-addressed storage systems.

The contenthash field supports several protocols, identified by codec in the multicodec format:

• IPFS — ipfs:// URIs pointing to immutable content on the IPFS network. The content hash encodes the CID (Content Identifier) of the root object. When you update your site, you publish a new version to IPFS and update the content hash record in ENS.
• Swarm — bzz:// URIs pointing to content on Ethereum Swarm, a decentralized storage platform closely integrated with the Ethereum ecosystem.
• Onion / Onion3 — Tor hidden service addresses.
• Arweave — ar:// URIs pointing to permanently stored content on the Arweave network.

Browsers that support ENS (such as Brave, or any browser with the MetaMask extension) resolve the content hash and fetch the content from the appropriate decentralized storage network. Gateways like eth.limo provide HTTP access for browsers without native ENS support: visiting yourname.eth.limo resolves the ENS content hash and proxies the IPFS/Swarm content over standard HTTP.

This creates a fully decentralized web stack: the name is on Ethereum (ENS), the content is on IPFS or Swarm, and no single server or company can take either offline. The website's availability depends only on the Ethereum network and the IPFS/Swarm network — both designed to be resilient and censorship-resistant.

ENS on Layer 2: CCIP-Read and Offchain Resolvers

Storing records on Ethereum mainnet costs gas, and gas is expensive. Setting a single text record can cost $5–50 depending on network congestion. This makes ENS impractical for frequent updates or for users who want many records without paying mainnet gas fees. CCIP-Read (Cross-Chain Interoperability Protocol Read, defined in EIP-3668) solves this by enabling resolvers to fetch data from offchain or Layer 2 sources while maintaining trustless verification.

Here is how CCIP-Read works in the context of ENS:

1. The client calls the offchain resolver on L1 to resolve a name.
2. The resolver does not have the data on-chain. Instead of returning a result, it reverts with an OffchainLookup error that contains a gateway URL and the callback function selector.
3. The client recognizes the OffchainLookup revert and sends an HTTP request to the specified gateway URL.
4. The gateway fetches the data from its backend (which could be a Layer 2 chain like Optimism or Arbitrum, a database, or any other source) and returns it along with a cryptographic proof.
5. The client sends the gateway's response back to the resolver's callback function on L1.
6. The resolver verifies the proof on-chain and returns the validated result to the client.

The critical security property is that the L1 resolver contract validates the proof. The gateway is untrusted — it cannot forge data because the proof must verify against on-chain state or a trusted signer. For L2-based resolvers, the proof is typically a Merkle proof against the L2's state root posted on L1. For simpler setups, it can be a signature from a trusted key.

CCIP-Read enables several important use cases: names whose records are stored on cheaper L2 chains (such as ENS on Optimism or Base), names issued by centralized services (like Coinbase's cb.id subnames that resolve via CCIP-Read), and DNS names imported into ENS using the DNSSEC oracle.

ENS vs DNS: Similarities and Differences

ENS was deliberately designed to mirror DNS in many ways. Both are hierarchical naming systems with dot-separated labels, both use resolvers to store records, and both support delegation of subdomains. But the underlying trust model and operational characteristics are fundamentally different.

An important convergence point: ENS supports DNS name imports via the DNSSEC oracle. If you own example.com and its DNS zone is DNSSEC-signed, you can prove ownership on-chain and use ENS as the resolver for example.com. This means ENS is not limited to .eth names — any DNSSEC-enabled DNS name can be imported into ENS and gain all the capabilities of ENS resolution (cryptocurrency addresses, text records, content hashes, etc.) while keeping its traditional DNS functionality.

From a networking perspective, DNS and ENS operate at completely different layers. DNS resolution depends on a globally distributed system of authoritative servers reachable via IP and BGP routing. ENS resolution depends on access to an Ethereum node (or a provider like Infura or Alchemy). The failure modes are entirely different: a DNS outage is a network infrastructure problem, while an ENS outage would require the Ethereum network itself to go down.

Wildcard Resolution (ENSIP-10)

Wildcard resolution, defined in ENSIP-10, allows a resolver to handle queries for names that do not have explicit records in the registry. This is analogous to DNS wildcard records, where *.example.com can match any subdomain.

When a client resolves anything.example.eth and the registry has no entry for that exact name, the resolution algorithm walks up the hierarchy: it checks anything.example.eth, then example.eth. If example.eth has a resolver that supports the resolve() function (the extended resolver interface), the client calls that resolver with the full original name anything.example.eth. The resolver can then dynamically generate a response.

This is what enables gasless subname issuance. A parent domain like example.eth can deploy a resolver that responds to any subname query by looking up data from an offchain database (via CCIP-Read). Thousands or millions of subnames can be issued without any on-chain transactions for each individual subname — only the parent domain's resolver needs to be set on-chain.

Real-world examples include Coinbase's cb.id names (every username.cb.id resolves through wildcard + CCIP-Read), and various projects that issue community subnames under a shared parent domain.

Subdomains

Like DNS, ENS is hierarchical. The owner of any name can create subdomains (also called subnames) without any permission from higher-level authorities. If you own example.eth, you can create blog.example.eth, wallet.example.eth, pay.example.eth, and so on, each with their own owner, resolver, and records.

There are two mechanisms for creating subdomains:

• On-chain subdomains — The parent name owner calls setSubnodeOwner() or setSubnodeRecord() on the registry, creating an explicit entry for the subname. This costs gas but gives the subname owner full on-chain control.
• Offchain subdomains — Using wildcard resolution and CCIP-Read, subnames can be resolved without any on-chain record. The parent domain's resolver handles all subname queries, fetching data from an offchain source. This is free for each individual subname (only the parent's resolver setup costs gas).

The Name Wrapper contract, introduced in ENS v3, adds sophisticated access control for subdomains. It wraps ENS names as ERC-1155 tokens and introduces "fuses" — permissions that can be irrevocably burned. For example, a parent can burn the CANNOT_UNWRAP fuse on a subname, guaranteeing that the subname owner has permanent control and the parent cannot reclaim it. Other fuses control whether the subname can be transferred, whether its resolver can be changed, and whether the parent can create subdomains under it.

This fuse system enables trust-minimized subname arrangements. A DAO could distribute subnames to members with burned fuses, guaranteeing that the DAO cannot later revoke them. An organization could issue employee subnames with recoverable fuses, retaining the ability to reclaim them if an employee leaves.

ENS DAO and Governance

The ENS protocol is governed by the ENS DAO, a decentralized autonomous organization that controls the root node of the ENS registry and the protocol's treasury. The DAO was established in November 2021 with the airdrop of the $ENS governance token to early adopters and contributors.

The DAO's powers include:

• Root node control — The ENS root node (namehash("")) is controlled by a multisig that executes DAO proposals. This gives the DAO the ability to create new TLDs within ENS (like .eth), update the .eth registrar, and manage the top of the naming hierarchy.
• Treasury management — All .eth registration and renewal fees flow to the DAO treasury. The DAO allocates funds for protocol development, ecosystem grants, public goods funding, and operational expenses.
• Protocol upgrades — Changes to the registrar (pricing, registration rules), the public resolver, and other protocol contracts go through the DAO's governance process: discussion, proposal, vote, and execution.
• Constitutional constraints — The ENS DAO operates under a constitution that includes articles like: names must not be revoked except through the standard expiration process, registration fees are capped at levels meant to discourage squatting without being prohibitive, and the DAO must act in the interest of the ENS community.

The governance structure is a hybrid: day-to-day operations are handled by ENS Labs (the core development company), funded by the DAO, while significant protocol changes require token-holder votes. Delegates play an important role — token holders can delegate their voting power to representatives who actively participate in governance discussions.

This governance model sits between the fully centralized ICANN hierarchy that governs traditional TLDs and the ungoverned nature of some other blockchain naming systems. The DAO provides a mechanism for the community to evolve the protocol while the constitution constrains its powers to prevent abuse.

ENS and the Traditional Internet

ENS does not exist in isolation from the traditional internet. Several bridges connect the two worlds:

• DNS integration — DNSSEC-enabled DNS names can be imported into ENS, giving traditional domains access to ENS's record types (crypto addresses, content hashes). This means yoursite.com can resolve to an Ethereum address for payments.
• HTTP gateways — Services like eth.limo and eth.link (now deprecated) provide HTTP access to ENS-hosted content. Visiting yourname.eth.limo in any browser resolves the ENS content hash and serves the content over standard HTTP.
• Browser support — Brave browser natively resolves .eth names. Other browsers can resolve them through extensions like MetaMask, which intercepts .eth URLs and routes them through ENS resolution.
• EIP-1185 — A standard for DNS record types within ENS, allowing ENS names to store A, AAAA, and other DNS records. This enables ENS names to function as DNS names when accessed through compatible resolvers.

From the perspective of internet infrastructure, ENS introduces a parallel naming layer that sits alongside DNS rather than replacing it. A single entity might have example.com in DNS (resolving through the traditional hierarchy of root servers, TLD servers, and authoritative servers, all reachable via BGP-routed IP addresses) and example.eth in ENS (resolving through Ethereum smart contracts). The two systems serve different audiences and offer different tradeoffs: DNS provides universal accessibility and fast resolution; ENS provides censorship resistance and native integration with the blockchain ecosystem.

Multichain Address Resolution

ENS is not limited to Ethereum addresses. The resolver's addr(node, coinType) function accepts a coin type parameter (defined in ENSIP-9, following the SLIP-44 standard) that specifies which blockchain's address to return. A single ENS name can store addresses for:

• Ethereum (coin type 60)
• Bitcoin (coin type 0)
• Litecoin (coin type 2)
• Solana (coin type 501)
• Any other blockchain registered in SLIP-44

This makes ENS a universal payment identifier. Instead of giving someone a different address for each blockchain, you give them your ENS name and their wallet resolves the correct address for the chain they are sending on. The addresses are stored as binary data (not strings) in the resolver, supporting any address format regardless of encoding scheme.

Security Considerations

ENS inherits Ethereum's security properties but introduces its own attack surfaces:

• Homoglyph attacks — Visually similar characters from different Unicode scripts can be used to create names that look identical to legitimate ones. ENS addresses this through name normalization (ENSIP-15, based on Unicode UTS-46), which defines canonical forms for names and rejects confusable characters. The normalization rules are strict: mixed-script names are generally forbidden, and certain characters are mapped to their canonical equivalents.
• Resolver trust — The owner of a name chooses its resolver. A malicious resolver could return incorrect data. Users should verify that names use trusted resolver contracts (like the Public Resolver) or review custom resolver code.
• Expiration sniping — Valuable names that expire could be immediately registered by bots. The premium auction mechanism (21-day exponential price decay) mitigates this, making sniping prohibitively expensive for most names.
• CCIP-Read gateway trust — For offchain-resolved names, the gateway is a point of centralization. While the L1 resolver verifies proofs, a compromised gateway could censor (refuse to return data) even if it cannot forge data. Redundant gateways and client-side retry logic mitigate this.
• Smart contract risk — Like all smart contract systems, ENS is subject to potential contract vulnerabilities. The core contracts have been extensively audited, but upgradeable components (like the registrar) introduce ongoing risk that is managed through the DAO governance process.

How ENS Connects to the Broader Infrastructure

While ENS operates on the Ethereum blockchain rather than traditional internet infrastructure, it is deeply connected to the same networks you can explore with a BGP looking glass. Ethereum nodes communicate over TCP/IP, which means every ENS resolution ultimately depends on BGP routing between autonomous systems. The RPC providers that most users rely on for ENS resolution — companies like Infura (operated by Consensys) and Alchemy — run infrastructure hosted on cloud providers like AWS (AS16509) and Google Cloud (AS15169).

IPFS gateways used to serve ENS-hosted websites are similarly dependent on traditional internet infrastructure. CDN providers like Cloudflare (AS13335) operate IPFS gateways, caching IPFS content at edge locations worldwide using anycast routing to minimize latency.

The eth.limo gateway, for example, must resolve ENS names, fetch content from IPFS, and serve it over HTTP — a chain that involves Ethereum RPC calls, IPFS network queries, and standard HTTP delivery, all flowing over BGP-routed IP networks. You can trace this infrastructure by looking up the IP addresses of these services:

• 1.1.1.1 — Cloudflare, which operates an IPFS gateway
• 8.8.8.8 — Google DNS, used by many Ethereum nodes for DNS resolution