ENS Explained: Turning Wallet Addresses Into Actual Names

Crypto has a UX problem.

Actually, crypto has many UX problems.

But one of the loudest ones is this:

0x8ba1f109551bD432803012645Ac136ddd64DBA72

That is not a username.

That is not an identity.

That is not something any normal human should be expected to read, remember, or confidently paste into a transfer screen while real money is on the line.

And yet, for years, this has been the vibe.

“Send funds to this 42-character hexadecimal string and please don’t mess it up.”

Very calming. Very consumer-friendly. Extremely normal.

ENS, short for Ethereum Name Service, is one of the cleaner attempts to fix that.

Instead of sending ETH or tokens to a wallet address like this:

0x8ba1f109551bD432803012645Ac136ddd64DBA72

you can send them to something like this:

alice.eth

Much better.

Still crypto. But with fewer jump scares.

So, what is ENS?

ENS is a naming system built on Ethereum.

It maps human-readable names to machine-readable things.

Most commonly:

alice.eth -> 0x1234...abcd

But ENS can do more than point to an Ethereum wallet.

An ENS name can store records like:

ETH address
Bitcoin address
Solana address
Avatar
Website URL
Email
GitHub username
X/Twitter handle
IPFS content hash
Custom text records

So your ENS name can become a portable web3 profile.

Not just “where do I send money?”

More like:

“Who is this person, what do they own, where is their stuff, and how do apps resolve that without everyone building their own cursed identity database?”

That is the product point.

ENS gives Ethereum a shared naming layer.

ENS is like DNS, but more onchain

The easiest comparison is DNS.

DNS is the system that turns domain names into IP addresses.

When you type:

google.com

your browser does not magically know where Google lives.

DNS helps resolve that name into the server information your computer needs.

Roughly:

google.com -> 142.250.x.x

ENS does a similar job, but for Ethereum and web3 resources.

alice.eth -> 0x1234...abcd

So yes, ENS is often described as “DNS for Ethereum.”

That is mostly fair.

But it is not perfect.

Because DNS and ENS have different assumptions.

DNS was built for the web.

ENS was built for wallets, ownership, smart contracts, and onchain identity.

Which means ENS is not just a lookup table. It is also tied to account ownership and smart contract logic.

DNS vs ENS

Here is the quick version:

Feature	DNS	ENS
Example	example.com	example.eth
Main use	Websites, email, servers	Wallets, profiles, web3 records
Resolves to	IP addresses, mail servers, text records	Wallets, content hashes, text records
Ownership	Registrar account	Ethereum account / smart contract
Infrastructure	DNS servers and registries	Ethereum smart contracts
Payments	Domain registration fees	ENS registration and renewal fees
Control	Registrar and DNS provider	Wallet-controlled onchain records
Portability	Web-native	Web3-native

DNS says:

Where is this website?

ENS says:

Who owns this name, and what records have they attached to it?

That distinction matters.

Because in crypto, identity and ownership are often the same conversation.

Your wallet is your login.

Your wallet is your account.

Your wallet is your money.

Your wallet is also, somehow, your profile picture and your reputation and your entire financial anxiety packed into one browser extension.

Normal stuff.

ENS gives that wallet a readable name.

Why wallet addresses are a UX tax

Wallet addresses are technically fine.

Computers love them.

Humans do not.

A wallet address is long, ugly, and unforgiving.

If you paste the wrong one, funds may be gone.

If malware swaps the address in your clipboard, good luck.

If someone asks you to verify the first 6 and last 4 characters, suddenly you are doing visual checksum meditation with real money.

0xA91...7F3b

Is that right?

Probably?

Maybe?

Pain.

ENS reduces that pain by giving users something recognizable.

chris.eth

That is not perfect security. You still need to verify what you are doing.

But it is a much better interface.

Names are easier to read.

Names are easier to remember.

Names are easier to display in apps.

And importantly, names are easier to build around.

How ENS works under the hood

ENS has three main pieces:

Registry
Resolver
Registrar

Let’s keep this simple.

1. The Registry

The ENS Registry is the core smart contract.

It keeps track of names.

For each ENS name, the registry stores:

owner
resolver
TTL

The owner controls the name.

The resolver tells apps where to look for the name’s records.

TTL is a caching value, similar to DNS.

The registry does not store every record directly.

That would get messy fast.

Instead, it points to a resolver.

2. The Resolver

The resolver is another smart contract.

It answers questions about a name.

Questions like:

What ETH address does this name resolve to?
What avatar is set?
What website does it point to?
What text records exist?
What content hash is attached?

So when an app wants to resolve alice.eth, it does not just ask one giant database.

It checks the ENS registry, finds the resolver, then asks the resolver for the records.

Very smart-contract-y.

Very “we added one more layer but it actually makes sense.”

3. The Registrar

The registrar controls how names are registered.

For .eth names, the .eth registrar handles registration and renewals.

This is the part users interact with when they buy or renew a name like:

mycoolstartup.eth

A registrar defines the rules.

Who can register?

For how long?

At what price?

What happens when it expires?

That kind of thing.

Namehash: the weird little detail you should know

Smart contracts do not love strings.

Strings are dynamic and awkward.

So ENS names are converted into a fixed bytes32 value called a namehash.

Example:

alice.eth -> namehash("alice.eth") -> bytes32

This lets contracts refer to names efficiently.

The important bit:

ENS contracts usually work with the namehash, not the plain text name.

So if you are building with ENS, you will often pass around a bytes32 node.

That node is the namehash.

Not scary.

Just slightly annoying.

As is tradition.

Resolving an ENS name in Solidity

Here is a simplified Solidity example.

This contract takes a namehash and resolves it to an Ethereum address.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface ENSRegistry {
    function resolver(bytes32 node) external view returns (address);
}

interface ENSResolver {
    function addr(bytes32 node) external view returns (address);
}

contract ENSLookup {
    ENSRegistry public ens;

    constructor(address ensRegistry) {
        ens = ENSRegistry(ensRegistry);
    }

    function resolve(bytes32 node) external view returns (address) {
        address resolverAddress = ens.resolver(node);
        require(resolverAddress != address(0), "No resolver set");

        ENSResolver resolver = ENSResolver(resolverAddress);
        return resolver.addr(node);
    }
}

On Ethereum mainnet, the ENS registry is commonly available at:

0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e

So the flow is:

name -> namehash -> registry -> resolver -> address

In code terms:

alice.eth
  -> bytes32 node
  -> find resolver
  -> ask resolver for addr(node)
  -> get wallet address

That is the core lookup path.

Setting records

ENS names can store different kinds of records.

The most obvious one is an address record.

alice.eth -> 0x1234...abcd

But text records are where ENS starts feeling more like identity infrastructure.

A profile can include records like:

avatar
url
com.github
com.twitter
description
email

For example:

com.github -> alice-dev
url -> https://alice.xyz
avatar -> ipfs://bafy...

Now apps can pull profile data from ENS instead of asking users to rebuild the same profile everywhere.

This is good.

Because filling out the same profile on 19 different crypto apps is not decentralization.

It is paperwork with gas fees.

ENS and websites

ENS can also point to decentralized content.

For example, you can attach a content hash that points to IPFS content.

Conceptually:

myproject.eth -> ipfs://bafy...

This lets an ENS name act like a web3-native website pointer.

Some browsers and gateways know how to handle this directly or through integrations.

So ENS is not only about wallets.

It can also connect names to content.

Again, like DNS.

But with web3 storage and onchain ownership mixed in.

Subnames: underrated and very useful

ENS names can have subnames.

If you own:

company.eth

you can create:

alice.company.eth
bob.company.eth
payroll.company.eth
docs.company.eth

This is powerful.

A DAO could issue member names.

A wallet app could give users free subnames.

A game could create player identities.

A company could organize departments or products.

Subnames make ENS more than a vanity handle market.

They make it programmable namespace infrastructure.

That sounds fancy, but the idea is simple:

If you own a name, you can build a naming system under it.

Why builders should care

ENS is useful because it gives apps a shared identity primitive.

Instead of showing:

0x71C7656EC7ab88b098defB751B7401B5f6d8976F

your app can show:

alice.eth

Instead of making every user upload an avatar, write a bio, and link their socials again, your app can read ENS records.

Instead of asking users to copy addresses into forms like it is 2017 and we all enjoy danger, your app can support ENS resolution.

This is one of those improvements that feels small until it is missing.

Like loading states.

Or undo buttons.

Or not making users bridge funds across three chains before breakfast.

But ENS is not magic

A readable name does not automatically mean safe.

Scammers can register lookalike names.

Users can still send funds to the wrong place.

Resolvers can be misconfigured.

Records can be outdated.

And if someone compromises the wallet that owns your ENS name, they can mess with your records.

So yes, ENS improves UX.

But apps still need to design carefully.

Show resolved addresses.

Warn on suspicious names.

Handle missing records.

Avoid blind trust.

Let users verify.

The goal is not “names fix everything.”

The goal is “names make the interface less hostile.”

That is already a win.

ENS in a product flow

A good ENS integration might look like this:

User types: alice.eth
App resolves the name
App displays: alice.eth -> 0x1234...abcd
User confirms
Transaction uses the resolved address

Do not hide the address completely.

That can be dangerous.

But do not force users to raw-dog hexadecimal strings either.

There is a middle ground.

Readable name first.

Resolved address visible.

Clear confirmation.

That is the kind of UX crypto needs more of.

Less “trust me bro.”

More “here is exactly what is happening.”

A tiny Solidity payment example

Here is a simplified example of sending ETH to an ENS-resolved address.

This is not production-ready.

It is just to show the shape.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface ENSRegistry {
    function resolver(bytes32 node) external view returns (address);
}

interface ENSResolver {
    function addr(bytes32 node) external view returns (address);
}

contract PayENS {
    ENSRegistry public ens;

    constructor(address ensRegistry) {
        ens = ENSRegistry(ensRegistry);
    }

    function resolve(bytes32 node) public view returns (address) {
        address resolverAddress = ens.resolver(node);
        require(resolverAddress != address(0), "No resolver");

        address recipient = ENSResolver(resolverAddress).addr(node);
        require(recipient != address(0), "No address record");

        return recipient;
    }

    function pay(bytes32 node) external payable {
        address recipient = resolve(node);

        (bool success, ) = payable(recipient).call{value: msg.value}("");
        require(success, "Payment failed");
    }
}

Again, real production code needs more thought.

You may want checks for resolver interface support.

You may want better error handling.

You may want to resolve offchain before the transaction to save gas.

You may want the user to confirm the resolved address in the frontend.

But the basic idea is straightforward:

ENS namehash in
wallet address out
payment sent

The bigger picture

ENS matters because crypto needs better handles.

Addresses are good for machines.

Names are good for humans.

And if crypto is supposed to be used by more than protocol engineers, MEV searchers, and people with six hardware wallets named after Greek letters, then readable identity matters.

ENS is not the whole answer.

It does not fix onboarding.

It does not fix seed phrases.

It does not fix bridging.

It does not fix the existential dread of signing a transaction that says “Set Approval For All.”

But it does fix one very real problem:

People need names.

Apps need a shared way to resolve those names.

And wallets need to stop looking like someone spilled alphabet soup into a hash function.

Final thoughts

ENS is one of the more practical pieces of Ethereum infrastructure.

It takes something painfully technical and gives it a human layer.

That is the kind of abstraction good products need.

Not abstraction that hides risk.

Abstraction that makes the system easier to understand and use.

DNS made the web usable by letting us type names instead of IP addresses.

ENS pushes Ethereum in the same direction.

From this:

0x8ba1f109551bD432803012645Ac136ddd64DBA72

to this:

yourname.eth

Small change.

Big UX upgrade.