ENS and Web3 Domain Names: Human-Readable Addresses that Travel With You

Introduction: Names turn copy-paste risk into recognizable identity

Human beings are good at remembering words and faces, not long hex strings. A naming system like Ethereum Name Service (ENS) lets you publish one human-readable handle (for example, you.eth) that dapps can resolve into the right addresses, profile text, and even a content pointer for a decentralized website. With one handle you can:

• Reduce mistakes: fewer mis-sent funds and fewer “triple-check” rituals.
• Unify presence: the same name and avatar appear across wallets, explorers, and apps.
• Delegate safely: create subdomains for teams and tools without giving away the crown jewel.
• Bring your brand: a consistent identity that follows you across apps and chains.

1) What ENS does in practice

ENS is an open naming protocol on Ethereum that maps a user-friendly label to structured data. When a wallet or dapp “resolves” you.eth, it typically asks the resolver contract for:

• Chain addresses: not just an Ethereum address, but also optional Bitcoin, a specific layer two address, or other networks that you choose to publish.
• Text records: website, email, social links, and a short bio or organization description.
• Avatar: a pointer to either an IPFS image or an on-chain NFT rendered as your profile picture.
• Content hash: a content-addressed pointer (for example, an IPFS CID) so you.eth can resolve to a decentralized site.

Because records live in a resolver contract that your registry entry points to, you can upgrade your resolver to gain new features without transferring ownership of the name. That separation is key for both safety and longevity.

2) ENS and similar naming systems (how to think about the landscape)

ENS is not the only naming game in town, but it is deeply integrated across the EVM ecosystem. Other systems include:

• DNS and traditional domains: the original naming system of the web. You can import DNS names into ENS via DNSSEC proofs so your .com brand can become a first-class on-chain name.
• Alternative Web3 namespaces: some projects issue names on other chains or with different trust models. They may offer useful UX features, but they are not drop-in compatible with ENS resolution unless bridged or mirrored.
• Chain-specific names: some ecosystems have their own native systems. These can be great locally but may not show up in generic EVM apps.

Decision lens: pick the system that shows up everywhere your users transact. For EVM apps and wallets, ENS is usually the default that “just works,” especially when you also publish per-chain addresses and set reverse correctly.

3) Architecture: registry, registrars, resolvers, and namehash

ENS is modular so policies can evolve without breaking the world. Four ideas matter in practice:

• Registry: the canonical contract that says, for a given name node, who the owner is and which resolver should answer questions. Think of it as the phonebook spine.
• Registrar: the policy for a top-level name like .eth. Today, .eth uses straightforward annual renewals with a short commit–reveal at registration time to prevent frontrunning. Other TLDs can plug in different policies.
• Resolver: the contract that actually stores records. Modern universal resolvers support many record types, including multi-coin addresses, text, avatar, and content hash.
• Namehash: names are addressed by a deterministic hash computed label by label. Contracts do not manipulate raw strings; they use this hash to look up the owner and resolver.

4) Register, renew, and configure without surprises

Step by step: from search to a live profile

1. Search for your name in the official ENS app or a trusted interface. Short names are scarce; consider adding a verb or context (for example, wisdomwrites.eth).
2. Register with commit–reveal. You first submit a commitment, then a short time later reveal it to finalize. This protects against frontrunners watching mempools.
3. Pick a registration length. One to three years is common. Longer gives fee stability and fewer renewals but ties up funds.
4. Set a resolver. Use a modern public resolver unless you have special requirements. You can change this later.
5. Publish records. Add your primary chain address, optional addresses for other chains, text, avatar, and a content hash if you host a site.
6. Set the reverse record from the address that should display your name. This is separate from forward records and is easy to forget. Do not skip it.

Renewals, grace, and reminders

.eth names follow an annual renewal model. After expiry there is a grace window when only the previous owner can reclaim. After grace, anyone can re-register the name. Treat the date like a production certificate renewal:

• Set calendar reminders at 90, 60, and 30 days before expiry.
• Keep a gas buffer for busy network days.
• Designate ops owners and controllers (explained below) so a hot wallet can edit records while a multisig guards ownership.

5) Records that matter: addresses, text, avatar, and content

The resolver is where dapps read data about your name. The most useful records are:

• Addresses: publish an address for Ethereum and any other chains you use. If you rotate a wallet, update the record and your public handle stays the same. Dapps should always resolve rather than hard-coding.
• Text records: website, description, contact method. Keep it high-level. Anyone can read this data forever, so avoid secrets.
• Avatar: either a content hash to an IPFS image or a pointer to an on-chain NFT. Using an NFT makes avatars portable across apps without re-uploading.
• Content hash: point you.eth to a decentralized site. Pin content through reliable pinning services to keep it available.

// Example: records you might publish
ETH                = 0xYourPrimaryEthAddress
OPTIMISM           = 0xYourL2Address
BITCOIN            = bc1qexample...
WEBSITE            = https://yourdomain.com
DESCRIPTION        = Research, writing, and dev tooling
AVATAR             = ipfs://<imageCID>  or  eip155:1/erc721:0xNFT.../123
CONTENTHASH        = ipfs://<siteCID>

Implementation tip: batch writes when possible so you do not leave the resolver in a half-updated state if a later transaction fails. If you switch resolvers, remember that records live in the resolver, not the registry, so you must set them again on the new resolver.

6) Reverse records: make apps show your name

Forward resolution goes from name → address. Reverse resolution goes from address → preferred name. Wallets and explorers will display your handle when you have a reverse record set for the sending address. Without it, they fall back to a raw hex string.

• Set reverse from the exact address you want associated with the name. Signing from a different address does nothing.
• Update reverse when you rotate a primary wallet or when a team changes which hot wallet initiates transactions.
• For organizations, set reverse on operational wallets like treasury.org.eth so activity reads clearly in dashboards and block explorers.

7) Subdomains and the NameWrapper: safe delegation patterns

Subdomains turn one name into a namespace you control. You can create ops.you.eth, grants.you.eth, or alice.team.eth and delegate each to a different address. The NameWrapper lets you “wrap” a name into a special token and burn fuses that permanently restrict risky actions. Examples of useful restrictions include:

• Cannot unwrap: prevents converting the name back to a bare registry entry.
• Cannot transfer: reduces the chance a delegated subdomain walks away to a new owner.
• Parent retains control: keeps the parent able to recover or update children according to a policy you define in advance.

Team pattern: keep the owner on a multisig or hardware wallet, designate a separate controller address for record edits, and wrap subdomains with appropriate fuses for contributors, apps, and automations. Write a short internal policy that lists who owns which subdomain, who can rotate keys, and under what conditions the parent can recover a child.

8) Advanced features: bring DNS, fetch off-chain data, and serve layer two users

DNS names inside ENS

You can import a traditional domain (for example, example.com) into ENS using DNSSEC proofs. That lets your web brand double as your on-chain name, which is helpful when your audience recognizes your dot-com more than a new .eth label. Once proven, the DNS name behaves like any other ENS name: publish resolver records, delegate subdomains, and set reverse (for an address you specify).

Off-chain resolution for richer data

Resolvers can serve some data from off-chain sources while remaining verifiable on chain. A pattern often called “CCIP-Read” allows a resolver to return a response signed by a trusted endpoint. The contract verifies the signature or Merkle proof and then emits the final result. This is useful for dynamic profiles or private metadata that you do not want to store directly on chain.

Layer twos and multi-chain reality

Many layer two apps already display ENS names. To keep the experience smooth:

• Publish an address for each chain where you expect to receive funds.
• Prefer content-addressed URLs for avatars and sites (IPFS) rather than centralized links.
• If a chain mirrors ENS locally, keep an eye on resolver compatibility so your profile renders consistently.

9) Developer patterns: resolve, reverse, and render safely

If you build wallets, dashboards, or any product that touches addresses, resolving names correctly is a quick win for UX.

Resolve a name to an address

// Pseudocode with a modern EVM library
const provider = new Provider(RPC_URL);
const addr = await provider.resolveName("you.eth"); // returns 0x... or null
if (!addr) throw new Error("Name not configured");

Reverse an address to a preferred name

const name = await provider.lookupAddress("0xYourAddress");
display(name ?? shortAddress("0xYourAddress"));

Read the avatar record and render

const resolver = await provider.getResolver("you.eth");
const avatar = await resolver?.getText("avatar");
// Render IPFS via a gateway of your choice or parse an NFT reference for on-chain rendering

Golden rules for integrators:

• Always checksum addresses and validate that a resolved address is not the zero address before showing “send” actions.
• Cache reads briefly while honoring TTL to reduce load and rate limits.
• Handle resolver migration by re-reading records if the resolver address changes.
• Expose a copyable link to a block explorer for transparency.

10) Safety, privacy, and operations playbook

A name is both a brand and a capability surface. Treat it like production infrastructure:

• Register and manage from the official app. Phishing sites love high-value names. Check URLs and signer prompts.
• Protect ownership with hardware or multisig. Keep the ownership NFT and registrar permissions in cold custody. Grant a separate controller for day-to-day record edits.
• Reduce personal data in text records. A public chain is forever. Use a generic contact method or a link to a page that you can edit off chain.
• Document delegation. When giving a team a subdomain, write down the owner address, intended use, and which fuses you burned.
• Set monitoring. Watch for resolver changes, record edits, and approaching renewals. Treat alerts like domain certificate expirations.
• Plan recovery. If a controller is compromised, you should be able to rotate to a fresh controller from the owner account quickly. If a child name is misused, use parent recovery options that your fuses allow.

11) Case studies and anti-patterns

Individual creator. A writer registers wisdom.eth and sets Ethereum and a layer two address, a website, and an NFT avatar. They set a reverse record on the wallet they use to receive payments. When they later rotate wallets, they update the address in one place and all their tip buttons and dapp interactions continue to work. Lesson: resolve first, hard-code never.

DAO with subdomain strategy. A community holds dao.eth in a multisig. It issues grants.dao.eth, ops.dao.eth, and treasury.dao.eth as wrapped subdomains with fuses that prevent transfer and unwrapping. Controllers are the relevant working groups. Lesson: separation of concerns reduces the blast radius of mistakes.

NFT project launching a site. The project publishes a marketing site to IPFS and sets the content hash on project.eth. A gateway and compatible browsers render the site at the name. When content changes, they pin the new CID and update the record. Lesson: content-addressed hosting pairs well with names.

Anti-patterns to avoid

• Skipping reverse: your name will not show up in most wallets and explorers. Set it for each sender.
• Publishing sensitive data in text records: everything is public and persistent. Use links instead of raw emails if privacy matters.
• Migrating resolvers without re-setting records: remember, the data is in the resolver. After a swap, republish your records.
• Giving contributors raw ownership of core names instead of subdomains: delegate with wrapped subdomains and fuses.
• Forgetting renewals: treat it like losing a domain name. Automate reminders and assign responsibility.

12) Frequently asked questions

Do I need to run a node to use ENS?

No. Most users interact through wallets and dapps. If you build products at scale, read records through healthy RPC providers and cache results with sensible time to live.

If I change wallets, do I lose my name?

No. The name is a token you own. You can transfer ownership or simply update the address records so the name points at a new wallet. Remember to update your reverse record on the new sender address too.

Can someone else claim my brand as a subdomain?

Only the owner or controller of the parent can create subdomains. If a third party owns a similar root, that is a different problem. Protect your brand by registering obvious variants and bringing your main DNS domain into ENS.

Is a private email safe in a text record?

No. Text records are public and easy to scrape. Use a contact link, a relay, or a form on your own site if you want the option to rotate or filter later.

What happens if I forget to renew?

There is a grace period when only the last owner can reclaim. After that, the name becomes available to others. Put renewals on a shared calendar and monitor on chain.

13) Glossary

• Registry: the core contract that stores the owner and resolver pointer for each name node.
• Registrar: policy contract that issues names for a suffix like .eth and enforces renewals.
• Resolver: the contract that holds the actual records (addresses, text, avatar, content hash).
• Namehash: a deterministic hash of a name used to look up entries on chain.
• Reverse record: a mapping from an address to a preferred name so UIs can display it.
• Subdomain: a child name under a parent, such as ops.you.eth.
• NameWrapper and fuses: a mechanism to wrap names and burn one-way restrictions for safer delegation.
• Content hash: a pointer to content addressed storage (for example, IPFS) rather than a location URL.

14) Key takeaways

• Names make crypto usable. Publish once and resolve everywhere.
• Understand the split: registry for pointers, registrar for policy, resolver for data.
• Set reverse on every address that sends or receives funds on your behalf.
• Delegate with subdomains and wrap with fuses so accidents do not become disasters.
• Keep public records non-sensitive. Use off-chain links for private or mutable information.
• Treat renewals and monitoring like production operations.

Go deeper

• Concepts to explore: resolver migration, batched writes, TTL, commit–reveal registration details.
• Operations: owner and controller roles, subdomain delegation checklists, renewal and change alerts.
• Content: pinning strategies for IPFS sites, avatar best practices, and safe gateway usage.

Quick check

1. What are the three core building blocks of ENS and what does each control?
2. Why is a reverse record essential for usability?
3. How do subdomains and fuses let teams delegate safely?
4. What belongs in resolver text records and what should stay off chain?

Next: non-transferable tokens for credentials and memberships.

Next: Soulbound Tokens →