ENS Lookup Guide: Resolve a .eth Name, Address, and Records

For prerequisite reading on the naming system itself, use ENS and Web3 Domain Names. Readers comparing naming ecosystems can also consult ENS vs Unstoppable Domains. This guide stays centered on a specific lookup: what a name or address resolves to now, how the result was produced, and what can safely be inferred from it.

What ENS is and what an ENS lookup does

The Ethereum Name Service is a hierarchical naming protocol specified initially in EIP-137. It maps names to resources through a registry and resolver model. A user can work with a readable name while applications retrieve machine-usable records such as Ethereum addresses, multichain addresses, content hashes, contract interfaces, and text metadata.

The simplest description is name to address, but a complete lookup has several layers. The client normalizes the input, derives its namehash or DNS-encoded representation, discovers the resolver, requests a specific record, handles wildcard or offchain behavior when necessary, decodes the result, and displays the evidence with the correct context.

The registry identifies ownership and resolver routing

The ENS registry maintains core information for names, including an owner field, resolver field, and time-to-live value. The owner can normally transfer the registry node, assign a resolver, and create or reassign subnames, subject to the registrar, wrapper, permissions, expiry, or other controlling contracts.

The registry is not usually where address, avatar, or text records are stored. Its resolver field points the lookup toward the contract responsible for answering those record requests.

The resolver answers record queries

A resolver implements one or more record interfaces. The common Ethereum address record uses an address-resolution function. Multichain address records use coin-type-aware formats. Text records return strings for defined keys. Contenthash records return encoded content addresses. Resolvers can be public shared contracts, custom onchain contracts, wildcard resolvers, or offchain-capable resolvers.

The registrar allocates names

A registrar controls allocation under a parent namespace. The .eth registrar manages second-level .eth registrations, renewal, expiration, and registration ownership. Other parents can create their own subname rules, while DNS names can be integrated through separate ENS mechanisms.

The lookup result is record-specific

A name does not resolve to one universal answer. It can have an Ethereum address, another-chain address, avatar, URL, email field, social handle, contenthash, contract ABI, or other resolver record. A lookup should state which record was requested and which resolver returned it.

Resolution and ownership answer different questions

Resolution asks what record the current resolver returns. Ownership asks which address or contract controls the name under the applicable registry, registrar, wrapper, or permission system. A name can resolve to a payment wallet that does not own or manage the name. This separation is useful for operational wallets, treasuries, multisigs, cold storage, and delegated profile management.

Forward resolution: name to address

Forward resolution begins with a name and requests a specific record. For an Ethereum payment lookup, the desired record is the Ethereum address associated with that name. The result should be treated as the current destination returned by the resolver, not a permanent property of the label.

Normalize the name before hashing or querying

ENS names can contain Unicode and require standardized normalization. Visually similar strings can have different code points, and some sequences are invalid or unsafe. Use an ENS-aware library or lookup tool that applies current normalization rules instead of manually lowercasing or hashing user input.

A displayed name should preserve enough information for the user to recognize confusable characters. When a high-value payment or brand identity is involved, compare the exact normalized name character by character.

Find the resolver

Traditional resolution derives the node for the name and asks the registry for its resolver. Modern universal-resolution paths can also locate an applicable parent resolver for wildcard names and support CCIP Read. If no resolver can be found, there is no record source for the requested lookup.

Request the Ethereum address record

The resolver returns the address record associated with the node or encoded name. A zero address or empty response generally means no usable Ethereum destination is configured through that record, although client behavior and resolver standards should be checked.

Display the complete destination

Wallet interfaces often shorten hexadecimal addresses. A lookup should expose the complete address and provide a copy action. Before sending funds, compare the beginning and end as a minimum, then verify the complete value through another trusted channel for material transfers.

Record changes can be immediate

The name owner or authorized record editor can update the resolver or address record according to the name's permission model. A destination used last month may differ today. Resolve immediately before each significant transfer rather than relying on screenshots, address books, or transaction history alone.

Forward resolution does not prove control of the destination

The name controller chose or authorized the record, but the destination wallet may be controlled by another person, a multisig, a smart account, an exchange deposit system, or a compromised key. Continue into wallet analysis when the relationship matters.

Reverse resolution: address to primary name

Reverse resolution begins with an address and asks which ENS name that address has configured as its primary name. Applications use this process to display names instead of raw hexadecimal addresses in wallets, explorers, chats, governance interfaces, and sign-in experiences.

The reverse namespace represents address claims

ENS reverse resolution uses a reverse naming system and reverse registrar mechanisms. The address or authorized contract sets a name record for its reverse node. This proves that the address authorized the reverse claim under the relevant mechanism.

A reverse record can contain any name string

The address can claim a name it does not own or a name that resolves somewhere else. This is why reverse lookup alone is insufficient for safe display. A malicious address could configure a reverse name resembling a trusted entity.

Primary name is a display preference

An address can be associated with many ENS names through forward records, but it usually chooses one primary name for reverse display in a given context. Primary-name support is also evolving toward multichain and chain-specific resolution, so clients should use standards-aware libraries rather than hard-coded assumptions.

Contracts and smart accounts can have primary names

A deployed contract, multisig, DAO treasury, or smart account can configure reverse resolution through supported ownership or authorization flows. The displayed name can therefore represent a protocol contract or organization-controlled account, not only an individual wallet.

Reverse lookup does not reveal every name pointing to the address

Many names can forward-resolve to one address. Reverse lookup returns the configured primary name, not a complete inventory of names, subnames, or historical labels associated with that address.

Why forward-confirming a reverse record matters

After reverse resolution returns a name, the client should perform forward resolution on that name and confirm that the result equals the original address. ENS documentation treats this forward confirmation as a required safety check for trustworthy display.

The verification loop

Suppose an application starts with address A. Reverse resolution returns example.eth. The application then resolves example.eth's Ethereum address record. Only when the forward result is also address A should the name be displayed as a confirmed primary-name relationship.

What a mismatch can mean

A mismatch can occur because the address set an arbitrary reverse name, the name changed its forward record, the name expired or transferred, records are stale, the client requested the wrong coin type, or offchain resolution failed. The application should fall back to the raw address or show the mismatch clearly.

Forward confirmation is not identity verification

The loop proves mutual configuration between the address's reverse claim and the name's forward record at lookup time. It does not prove the legal or social identity implied by the name. A scammer can control both a copycat name and the address it resolves to.

Recheck after transfers and record updates

If ownership or the forward address changes, an older reverse record can stop matching. Applications should perform the check at display time and should not cache a verified label indefinitely.

Step by step: search a .eth name or Ethereum address

A dependable lookup follows the same evidence sequence whether the starting input is a name copied from a profile or an address copied from a transaction.

Search by name

Enter the full name, including every subname label and the .eth suffix. Confirm normalization. Review the resolved Ethereum address, resolver address, ownership state, expiration, reverse consistency, and available records.

Search by address

Enter the complete 0x address. Read the configured primary name, then forward-confirm it. If no primary name exists or confirmation fails, continue to use the raw address rather than assigning a name from another source.

Choose the correct address record

ENS can store records for multiple coin types. For an Ethereum payment, use the Ethereum record. For another chain, use the chain's supported record and validate its encoding. Do not reuse an Ethereum destination automatically for Bitcoin, Solana, or another network.

Record lookup time and source

For compliance, treasury, support, or incident work, record when the lookup was performed, which resolver answered, which address or name was returned, and whether reverse confirmation passed. Records can change after the lookup.

Do not send from the first result alone

For high-value transfers, verify the name through an independent official channel, compare the resolved address with a previously authenticated value, and use a small test transaction when appropriate. ENS reduces transcription risk but does not eliminate social engineering.

Address records, text records, avatar, contenthash, and resolver context

An ENS profile can expose several record categories. Each category answers a different question and carries a different trust level.

Ethereum address record

The Ethereum address record is the primary payment and account-routing result for most .eth lookups. It can point to an externally owned wallet, smart account, multisig, contract, exchange deposit address, or another operational destination.

Multichain address records

ENS resolver profiles support address records identified by coin type. These records are encoded as bytes and must be decoded according to the destination chain's address format. A name can therefore publish different destinations for Ethereum, Bitcoin, and other supported ecosystems.

Presence of a record does not prove that the address is controlled safely or that the asset should be sent on that network. Confirm chain, asset, memo requirements, and recipient support independently.

Text records

Text records are arbitrary key-value strings under standardized or custom keys. Common examples include email, URL, description, social handles, notice, keywords, avatar, and profile fields. They improve discoverability but are controlled by the name's authorized record editor.

A text record claiming official support, employment, legal status, investment terms, or recovery instructions is not independently verified by ENS. Confirm through authenticated organizational channels.

Avatar record

The avatar text record can contain a direct image URI, content-addressed resource, data URI, or supported NFT reference. Clients may perform additional ownership checks for NFT-backed avatars. The displayed image can change, fail to load, or originate from an external gateway.

Avatars are visual metadata. A copied logo or portrait can strengthen impersonation, so never treat image familiarity as address verification.

Contenthash record

The contenthash field maps a name to content-addressed or decentralized content systems using a standardized encoding. It can support websites and other resources without a conventional centralized hostname.

Opening content linked by a name carries normal browsing and application risk. The content can contain phishing interfaces, malicious signing requests, or outdated information even when the contenthash resolves correctly.

Resolver address

The resolver address reveals which contract or resolution system supplied the records. A current public resolver is common, but custom resolvers may implement specialized permissions, wildcard behavior, L2 records, or offchain data.

Changing the resolver can effectively replace the source of every record. Review resolver changes and custom code when the name supports a treasury, protocol, brand, or high-value identity.

TTL

The registry can store a time-to-live hint for caching. Applications may cache according to their own policy, and blockchain or offchain records can change. A cached result should not be used indefinitely for financial decisions.

Owner, manager, registrant, resolver, and record-controller differences

ENS interfaces have evolved, and role labels can vary across registrar, registry, wrapper, application, and protocol generation. The safe approach is to map each power directly instead of assuming one address controls everything.

Registry owner

The registry owner is the address or contract in the registry's owner field. It can normally assign a resolver, change ownership, and create subnames, subject to the name's governing contracts and permissions.

.eth registration holder or registrant

The .eth registrar maintains registration ownership and expiration for second-level .eth names. The registration holder controls the registrar token or equivalent registration right and can normally transfer it or renew the name while the registration remains valid.

Registration ownership is distinct from the registry owner field. In an unwrapped .eth architecture, the registration holder and registry manager can be separated for operational security.

Manager

Manager is commonly used for the address that controls registry-level management of an unwrapped .eth name, including resolver and subname operations, while another address retains the registration ownership. Exact powers should be checked from the current contracts and interface.

Wrapped-name holder

The ENS Name Wrapper can hold the underlying registry or registrar ownership and issue an ERC-1155 token representing the wrapped name. Fuses and expiry can restrict transfer, resolver changes, subname creation, unwrapping, or parent control.

For a wrapped name, inspect the wrapper token owner, fuse state, expiry, approved operators, and whether the name is wrapped, emancipated, or locked. The visible NFT holder does not imply that every permission remains unrestricted.

Resolver

The resolver is not necessarily the owner. It is the contract that returns records. A shared public resolver can serve many unrelated names. A custom resolver can delegate writing or perform offchain resolution.

Record controller or authorized editor

Record controller is a practical description for an address allowed to change records under the resolver's authorization model. The resolver may permit the name owner, approved delegates, operators, or contract-specific roles to update records.

A payment address can therefore change without transferring the name. Review resolver authorization when operational separation or compromise is suspected.

Subname parent controller

The owner of a parent such as organization.eth can create and manage subnames unless permissions, wrapping, or fuses restrict that control. A subname holder may have strong ownership guarantees or may remain replaceable by the parent.

Expired names, wrapped names, subdomains, and offchain resolution

A lookup can return a technically valid record while the name is expired, in a restricted lifecycle stage, inherited through a parent resolver, or answered by an offchain gateway. These conditions belong in the result.

.eth expiration and grace period

Under the current .eth registration lifecycle, an expired name enters a 90-day grace period. During that period the original holder can extend it at the standard renewal price, nobody else can register it, and records can continue resolving, although management actions can be restricted.

After the grace period, the name enters temporary premium availability and must be registered as a new name. The prior holder loses priority. A name remembered from an earlier payment can therefore come under new control after expiration and re-registration.

Why status must be checked before sending

A name can continue displaying old records during part of its expiry lifecycle, and external applications may cache results. Recheck expiration, registration ownership, and current resolution immediately before a material transfer.

Wrapped names

Wrapping converts name control into an ERC-1155 representation managed by the Name Wrapper. The holder can gain standardized permissions and can burn fuses that permanently restrict selected powers until expiry.

A wrapped .eth second-level name is automatically emancipated from parent control. Wrapped subnames can have different guarantees depending on fuses, locking, parent control, and expiry. A lookup should not flatten these states into one owner label.

Subnames

Names such as pay.organization.eth and support.organization.eth are subnames. The parent can assign separate owners, resolvers, records, and expirations, or use wildcard resolution to answer many subnames dynamically.

A subname can be useful for role separation, but it can also be used for impersonation. Verify the parent name, exact label, issuer, ownership guarantees, and whether the parent can replace the record.

Wildcard resolution

A wildcard resolver can answer for a subname that has no individual resolver or may not exist as a separate registry entry. The client searches up the hierarchy for an extended resolver and supplies the full encoded name.

This means absence of an individual onchain node does not necessarily mean the subname cannot resolve. The lookup should identify the parent resolver that supplied the answer.

CCIP Read and offchain records

An offchain-capable resolver can return an OffchainLookup request containing authorized gateway information. A compatible client retrieves data from the gateway and calls the resolver's callback function, where the response is verified according to the resolver's logic.

CCIP Read does not mean the client should trust arbitrary HTTP data. The resolver defines the verification path, and the client must support the standard correctly. Gateway availability and data-source transparency can affect lookup reliability.

Resolver compatibility differences

Older wallets and applications may not support wildcard or CCIP Read resolution. One interface may return a record while another reports no result. Compare resolver support before concluding that the record is invalid.

ENS verification loop

The safest lookup joins resolution, reverse confirmation, ownership context, and wallet analysis. On mobile, the same logic appears as stacked cards to avoid compressed diagram text.

Common ENS impersonation and copycat-name risks

Human-readable names reduce address complexity but introduce the same visual and social-engineering risks found in usernames, email domains, and web addresses.

Lookalike Unicode characters

Characters from different scripts can resemble Latin letters. Combining marks and visually similar symbols can produce names that appear identical in some fonts. Use normalized display, character inspection, and trusted links for high-value identities.

Misspellings and transposed letters

A copycat can register a one-character variation of a brand, founder, DAO, or support name. Read the full label rather than relying on visual recognition.

Misleading subnames

A name such as trustedbrand.attacker.eth is controlled under attacker.eth, not trustedbrand.eth. Read names from right to left to identify the parent hierarchy. The authoritative parent is the label immediately before .eth and its ancestors.

Copycat text records and avatars

Attackers can copy profile pictures, URLs, biographies, and social handles into records they control. Metadata similarity does not establish ownership of another identity.

Old screenshots and cached results

A legitimate name can change address, expire, transfer, or be re-registered. A screenshot proving an earlier result is not proof of the current destination.

Reverse-only impersonation

An attacker can configure a reverse record naming a trusted .eth label without controlling it. Forward confirmation prevents this reverse-only claim from being displayed as verified.

Compromised legitimate name

The exact official name can be controlled by a compromised wallet, malicious record delegate, hacked manager, or unsafe resolver. Correct spelling and forward-reverse consistency do not rule out compromise.

Expired and re-registered name

A name can belong to a new controller after its grace period and premium lifecycle. Historical reputation does not transfer safely to the new holder.

False support identities

Scammers use support-like names and text records to request seed phrases, wallet connections, remote access, or recovery payments. Legitimate support does not need recovery words or private keys.

The Top ENS and Web3 Domain Mistakes guide covers normalization, renewal, ownership separation, copied names, and operational errors that can affect both buyers and recipients.

How to verify an ENS identity before sending funds or assigning trust

ENS is strongest as one authenticated signal inside a broader verification process. The required depth should match the value and consequence of the decision.

Verify through an independent official channel

Confirm the exact .eth name or resolved address through a company's official website, a previously authenticated chat, a signed announcement, a known governance proposal, or an established contact method. Do not use a link supplied only by the person requesting payment.

Perform forward and reverse checks

Resolve the name to the address. Reverse-resolve the address. Forward-confirm the returned primary name. A mismatch requires explanation before proceeding.

Inspect ownership and record control

Determine whether the name is owned by the expected treasury, multisig, individual, wrapper, or registrar contract. Check whether another address can edit records. Operational delegation can be legitimate, but it changes the compromise surface.

Review expiration and transfer history

Confirm that the name is active, has not recently changed ownership, and is not near expiry when continuity matters. A recently re-registered name deserves heightened scrutiny.

Check the resolved account type

Determine whether the destination is an externally owned wallet, multisig, smart account, token contract, protocol contract, exchange deposit address, or newly deployed account. The expected type should match the claim.

Compare transaction history with the claimed role

A DAO treasury should show governance or operational patterns consistent with that role. A payment address may have normal incoming and outgoing activity. A newly funded wallet with no prior relationship to the entity requires additional verification.

Use a test transaction where appropriate

Send a small amount first when the asset and network support practical testing. Confirm receipt through an authenticated channel before sending the balance. A test cannot repair a malicious recipient, but it can catch network, record, and transcription mistakes.

Do not infer identity from balance or popularity

High balances, NFTs, transaction volume, long history, and popular ENS labels can be bought, transferred, or compromised. They are context, not identity proof.

When to continue with wallet-risk analysis

A simple lookup may be enough for low-consequence address readability. Continue into wallet analysis whenever a wrong conclusion can cause financial loss, reputational harm, access compromise, or operational disruption.

Before a material payment

Review the resolved wallet's age, funding, transaction pattern, contract interactions, exchange exposure, counterparties, and whether it has received prior legitimate payments from the same relationship.

Before trusting a support or recovery contact

A support-themed ENS name does not prove affiliation. Verify official channels and scan the wallet for mass inbound payments, rapid forwarding, drainer interactions, and other suspicious patterns.

Before accepting a DAO or treasury instruction

Confirm the destination against governance calldata, proposal text, multisig ownership, previous treasury transactions, and on-chain role assignments. A text record is not sufficient authorization.

After an unexpected record change

If a known name resolves to a new address, inspect the record-change transaction, manager, resolver, ownership transfer, and destination wallet. Treat unexplained changes as incidents until verified.

When a primary name appears on an unfamiliar address

Forward-confirm the name, then inspect whether the address recently acquired the name, whether the records changed, and whether activity matches the claimed entity.

When the destination is a contract

Identify contract purpose, verification, proxy status, implementation, administrator, token-handling behavior, and whether sending directly is supported. Tokens sent to the wrong contract may be unrecoverable.

When records point across chains

Confirm the correct multichain address record, destination format, network support, and whether the receiving service requires a memo or tag. Wallet-risk evidence is chain-specific.

Protecting the name owner and record controller

Lookup safety depends on the security of the addresses that own the registration, manage the name, edit resolver records, and set the primary name.

Separate ownership from routine record management

A long-term owner can delegate management or record editing to a lower-value operational wallet where supported. This reduces exposure of the registration while preserving the ability to update payment and profile records.

Use multisig control for organizational names

DAOs, protocols, and brands should avoid one personal key controlling ownership and resolver changes. Use a reviewed multisig with appropriate threshold, independent signers, secure modules, and documented recovery.

Monitor owner, resolver, and record changes

Alerts should cover registration transfers, wrapper transfers, resolver updates, address-record changes, delegate assignments, primary-name updates, expiry, and renewal. Monitoring reduces the time between compromise and detection.

Renew with operational margin

Do not depend on last-minute renewal. Extend important names far enough ahead to survive key rotation, governance delay, gas spikes, personnel absence, and application outages.

Secure signing keys

A hardware wallet such as Ledger can isolate the signing key used for long-term name ownership. It cannot verify organizational intent automatically, so confirm contract addresses, resolver changes, wrapper permissions, transfers, and renewal transactions before approval.

Document the identity architecture

Organizations should record which address owns the name, which address manages it, which resolver is used, who can edit records, which wallet receives payments, and how emergency rotation works. Public documentation helps users verify unexpected changes.

The Secure Your Web3 Identity guide covers wallet separation, sign-in requests, profile records, avatars, recovery, impersonation, and operational controls in greater depth.

Worked examples: resolving and verifying ENS records

Example one: name resolves correctly but has no reverse match

Alice receives payments at alice-example.eth. Forward resolution returns address A. Reverse lookup on address A returns no primary name.

The payment destination can still be valid because reverse configuration is optional. The lookup should report the forward address and absence of a primary name without calling the destination invalid. Alice can set a primary name if she wants applications to display it.

Example two: reverse name fails forward confirmation

Address B reverse-resolves to famousbrand.eth, but forward resolution of famousbrand.eth returns address C. The address should not be displayed as famousbrand.eth.

The mismatch can result from impersonation or stale configuration. Use address B as the identifier and verify both parties independently.

Example three: a payment subname uses wildcard resolution

pay.customer.organization.eth has no separate resolver entry. The Universal Resolver finds a wildcard resolver at organization.eth, which returns a dynamically assigned customer payment address.

The result can be valid even though the subname does not exist as an individual registry node. The lookup should identify the parent wildcard resolver and verify the issuer's official system before payment.

Example four: old .eth name was re-registered

A user paid oldmerchant.eth two years ago and saved the name. The original holder failed to renew, the grace period ended, and another party registered it. The name now resolves to a new address.

Historical use does not authenticate current control. The user must verify the merchant's current official channel and should not rely on the old transaction history alone.

Example five: Ethereum and Bitcoin records differ

treasury.eth publishes an Ethereum address and a Bitcoin address. A sender copies the Ethereum result into a Bitcoin withdrawal form.

The lookup should expose record type and encoding clearly. The sender must request the Bitcoin record for the intended network. A name can map to several chain-specific destinations without one replacing the others.

Example six: wrapped subname has restricted control

member.community.eth is wrapped and held by the member. Fuses prevent parent replacement and restrict resolver changes until expiry.

The lookup should show the wrapped owner and fuse context. The parent label alone does not reveal whether the parent can revoke or alter the subname.

Example seven: legitimate name points to a new multisig

A DAO rotates its treasury. The official governance proposal changes dao.eth from an old multisig to a new one. Reverse resolution on the new multisig is configured and forward-confirmed.

The change can be legitimate, but users should verify governance execution, multisig threshold, signer policy, and wallet history before updating payment or accounting systems.

Example eight: avatar and text records copy a founder

A lookalike name uses the founder's portrait, social handle, website, and biography. Forward and reverse resolution are internally consistent with the attacker's wallet.

ENS confirms the attacker's control of the copycat name, not the founder's identity. Exact spelling, official-channel confirmation, and wallet analysis expose the impersonation risk.

Example nine: offchain resolver works in one wallet only

A subname uses CCIP Read. A modern lookup resolves it, while an older wallet reports no address because it does not support the offchain resolution flow.

The discrepancy is a client-compatibility issue rather than proof that the record is fraudulent. The sender should still verify the resolver, gateway verification path, issuer, and destination through a supported client.

Example ten: contract address has a verified primary name

A protocol contract reverse-resolves to vault.protocol.eth, and forward resolution returns the same contract address. The code is an upgradeable proxy.

The name relationship is valid, but the contract's implementation and administrator remain separate risks. Resolve the name, then inspect the proxy and active implementation before interacting.

ENS lookup checklists for individuals, DAOs, brands, and support teams

Individual payment checklist

DAO and treasury checklist

Brand and public-identity checklist

Support and incident-response checklist

How to read confirmed, observed, inferred, and unresolved findings

An ENS lookup combines direct protocol data with identity and risk interpretation. Keep those evidence levels separate.

Confirmed resolution is not confirmed identity

The resolver can prove that a name returns an address. It cannot prove the human or organization controlling the destination unless another authenticated system establishes that relationship.

Observed wallet history is not intent

A wallet can receive funds from an entity without belonging to it. Contract interactions, labels, balances, and counterparties should be interpreted cautiously.

Inferred claims need independent confirmation

A text record, avatar, and matching social handle can all be copied. Use official websites, governance, signed statements, and prior authenticated communication.

Unresolved resolution should block irreversible action

If a client cannot support the resolver, expiration is unclear, forward confirmation fails, or the destination changed unexpectedly, pause the payment or identity decision until the gap is resolved.

Common mistakes when performing an ENS lookup

Trusting reverse resolution without forward confirmation

An address can claim a name it does not control. Always resolve the returned name and require it to point back to the original address.

Assuming a .eth label proves identity

ENS proves control relationships, not legal identity, employment, endorsement, or reputation.

Ignoring Unicode and copycat spelling

Normalize the name and inspect every character before high-value use.

Reading a subname from left to right only

Identify the parent hierarchy. support.brand.attacker.eth belongs under attacker.eth, not brand.eth.

Using a cached address

Resolve again before every material transfer because records and resolvers can change.

Ignoring expiry

An expired name can eventually be re-registered by another party. Historical reputation does not authenticate the current holder.

Confusing owner with payment address

The name owner, manager, resolver controller, and resolved wallet can be different addresses.

Assuming no registry node means no subname

Wildcard and offchain resolvers can answer for names that do not exist individually onchain.

Using the Ethereum address for another chain

Request the correct coin-type record and verify address encoding for the destination network.

Trusting avatars and text records

These are controlled metadata and can be copied or changed.

Ignoring resolver changes

A resolver update can replace every record source without transferring the name.

Assuming a verified primary name means a safe wallet

Forward-reverse consistency proves configuration, not wallet safety, contract security, or honest intent.

Sending directly to a contract without checking its purpose

A resolved contract may not accept direct transfers or may be upgradeable. Inspect it first.

Using one interface as the only source

Client support for CCIP Read, wildcard resolution, caching, and records can differ. Cross-check material results.

Conclusion: resolve the record, verify the loop, then evaluate trust

An ENS lookup should begin with an exact normalized input. When the input is a name, discover the resolver and request the correct address or metadata record. When the input is an address, retrieve its primary name and forward-resolve that name back to the original address before displaying it as confirmed.

The result must retain context. The registry owner, .eth registration holder, manager, wrapped-name holder, resolver, record editor, reverse-name controller, and payment destination can be different addresses. A name can also use wildcard or offchain resolution, chain-specific address records, parent-controlled subnames, and wrapper restrictions.

Expiration matters because a familiar .eth name can eventually pass to a new controller. Metadata matters because avatars and text fields can strengthen impersonation while remaining user-controlled claims. Resolver context matters because changing the resolver can replace the source of every record.

Use the ENS Name Checker for the specific name or address, ENS and Web3 Domain Names for protocol background, the comparison and domain-mistake guides for ecosystem and registration context, and Secure Your Web3 Identity for owner protection.

When the lookup supports a payment, treasury instruction, support claim, employment identity, governance action, or public brand, continue into the Wallet Risk Scanner. ENS makes addresses readable. Trust still requires independent evidence about the person, organization, wallet, contract, and transaction involved.

FAQs

References and further learning

The following official standards and ENS documentation provide additional detail on registry resolution, primary names, resolver records, multichain addresses, text records, contenthash, wildcard resolution, CCIP Read, wrapping, and name lifecycle.

• EIP-137: Ethereum Domain Name Service
• ENS Documentation: Resolution
• ENS Documentation: Primary Names and Reverse Resolution
• ENS Documentation: Address Lookup
• ENS Documentation: The Registry
• ENS Documentation: Public Resolver
• ENSIP-5: Text Records
• ENSIP-7: Contenthash Field
• ENSIP-9: Multichain Address Resolution
• EIP-2544: ENS Wildcard Resolution
• EIP-3668: CCIP Read
• ENS Documentation: Name Wrapper
• ENS Support: .eth Name Lifecycle

This TokenToolHub guide is educational research only. It is not an identity certification, legal opinion, financial advice, cybersecurity assurance, or guarantee that an ENS name, resolver, record, wallet, contract, website, or controller is safe. Verify the normalized name, resolver path, address record, reverse confirmation, ownership and permission state, expiration, authenticated communication, and wallet activity before sending funds or assigning trust.