Reverse resolution is the complementary process to forward resolution (e.g., resolving vitalik.eth to 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045). While forward resolution finds the address associated with a name, reverse resolution answers the question, "What name is associated with this address?" This is achieved by querying a smart contract, typically a registry or a dedicated reverse registrar, that stores the canonical mapping from an address back to its primary domain. The most common standard for this on Ethereum and other EVM chains is EIP-181.
LABS
Glossary
Reverse Resolution
Reverse resolution is a service that maps a blockchain address or asset identifier to a human-readable name or metadata, such as resolving an Ethereum address to an ENS name.
Chainscore © 2026
definition
BLOCKCHAIN IDENTITY
What is Reverse Resolution?
Reverse resolution is the process of mapping a blockchain address to a human-readable identifier, such as a domain name or username, to reveal the identity behind a public key.
The technical mechanism relies on a specialized namehash for the reverse namespace. For Ethereum, this is addr.reverse. To resolve an address like 0x1234..., a resolver contract is queried for the record associated with the namehash of 1234....addr.reverse. The resolver then returns the associated canonical domain name, such as alice.eth. This process is fundamental for blockchain explorers, wallets, and dApps to display user-friendly identifiers instead of long hexadecimal addresses, enhancing transparency and usability.
Implementing reverse resolution requires the address owner to explicitly set a reverse record. This is a separate, often manual, transaction where the owner authorizes a specific domain (like their ENS name) to represent their address. This one-to-one mapping means an address can have only one primary reverse record, though it may own many domains. The security model is self-sovereign; only the private key controlling the address can set or update its reverse record, preventing impersonation.
Key use cases extend across the ecosystem: - Wallet Display: Showing bob.eth instead of 0x1a2b... in transaction histories. - Credential Verification: Allowing users to prove control of a specific named identity for decentralized applications. - Reputation Systems: Linking on-chain activity and social graphs to a persistent, readable identifier. - Customer Support: Enabling services to identify users by name instead of an opaque address string.
While Ethereum Name Service (ENS) popularized the standard via EIP-181, other networks and naming systems like Unstoppable Domains, SPL Name Service on Solana, and Lens Protocol handles implement similar reverse resolution mechanics. The limitations include optional adoption (not all addresses set a record), potential for stale data, and the fact that it reveals only the claimed identity, which should be cross-referenced with forward resolution for verification.
how-it-works
MECHANISM
How Does Reverse Resolution Work?
Reverse resolution is the process of looking up a human-readable name associated with a blockchain address, such as an Ethereum Name Service (ENS) domain for a wallet's public key.
Reverse resolution is the complementary process to forward resolution (looking up an address from a name). While forward resolution answers "What address does vitalik.eth point to?", reverse resolution answers "What readable name, if any, is associated with 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?" This is achieved by querying a dedicated, standardized reverse resolution record stored on-chain. For ENS, this is managed through a special-purpose registrar for the .addr.reverse domain.
The technical mechanism involves a smart contract, the Reverse Registrar, which maintains a mapping. When a user sets a primary name for their address, they interact with this registrar. The contract creates or updates a record in the reverse zone (e.g., 45.0.6.AA.37.D.5.4.3.E.0.9.e.D.7.e.e.D.9.F.B.F.A.6.d8.addr.reverse for the address above) that points to the canonical name like vitalik.eth. Applications then query this reverse record using a standard function like ENS.reverseResolve() to retrieve the name.
For a reverse record to be considered authoritative and trustworthy, it must pass a reverse resolution check. This verification confirms that the name discovered (e.g., vitalik.eth) itself forward-resolves back to the original querying address. This two-way verification, known as a resolution chain, prevents spoofing and ensures the name is genuinely owned by the address holder. Without this check, a malicious actor could point a reverse record to any name they do not own.
Reverse resolution is a foundational identity primitive for Web3 user interfaces. It enables wallets, explorers, and dApps to display human-readable names instead of long hexadecimal addresses, drastically improving usability and reducing errors. Common implementations include the Ethereum Name Service (ENS) reverse resolver and similar systems in other naming services like Unstoppable Domains and Space ID. The ERC-181 standard formally defines the reverse resolution process for Ethereum.
From a developer's perspective, integrating reverse resolution typically involves using a library like ethers.js or web3.js to call the resolver contract. The process is: 1) Take a user's address, 2) Generate the reverse node (a namehash of the reversed address in the .addr.reverse domain), 3) Query the resolver for that node, and 4) Validate the result by performing a forward lookup. This ensures the displayed name is both readable and cryptographically verified.
key-features
REVERSE RESOLUTION
Key Features
Reverse resolution is a blockchain protocol that maps a wallet address to a human-readable name, the inverse of traditional name services. This section details its core mechanisms and applications.
01
Address-to-Name Mapping
Reverse resolution flips the standard forward resolution model (e.g., vitalik.eth → 0xd8dA...) by allowing a smart contract to store which name is associated with a given address. This enables applications to display a user's chosen ENS name, Unstoppable Domain, or other identifier when viewing their wallet address, improving UX across dApps and explorers.
02
ERC-1812 Standard
The canonical technical specification for Ethereum reverse resolution is ERC-1812. It defines a standard interface (reverseResolverOf) that contracts like ENS's Reverse Registrar implement. This allows any compliant contract to resolve an address to its canonical name record, ensuring interoperability across the ecosystem.
03
Primary Use Case: dApp Interfaces
The most common application is in wallet and dApp user interfaces. Instead of showing a truncated, impersonal address like 0x4bbe..., applications query the reverse resolver to display a verified name. This is critical for:
- Social dApps and marketplaces showing usernames.
- DeFi dashboards identifying known entity addresses.
- Transaction histories making flows readable.
04
Decentralized Identity & Reputation
Reverse resolution is a foundational layer for decentralized identity (DID). By allowing an address to claim a persistent, verifiable name, it enables:
- Portable reputation across platforms.
- Trust signals from known entities in governance or DAOs.
- Anti-phishing by confirming a name matches the expected address for a transaction.
05
The Resolution Process
A reverse lookup involves a specific query path:
- The application takes the target Ethereum address.
- It computes the reverse record's lookup address (e.g.,
[addr].addr.reversefor ENS). - It queries the resolver contract at that address for the associated name.
- The resolver returns the name, which may then undergo a forward resolution to verify its correctness.
06
Contrast with Forward Resolution
It's essential to distinguish the two directions of resolution:
- Forward Resolution (Name → Address): Used to send funds or interact with a named entity. The source of truth is the name's record.
- Reverse Resolution (Address → Name): Used to display identity. The source of truth is the address's claim to a name. A name resolved in reverse should always be verified by a subsequent forward lookup to prevent spoofing.
examples
REVERSE RESOLUTION
Examples & Implementations
Reverse resolution is implemented across various blockchains and services to map a blockchain address back to a human-readable name. Here are key platforms and use cases.
04
Wallet & DApp Integration
Major wallets and DApps implement reverse resolution APIs to improve user experience.
- MetaMask: Displays a user's primary ENS name in the account view if reverse resolution is set.
- Etherscan: Shows the ENS name associated with an address at the top of its address page.
- DApp Frontends: Use libraries like
ethers-ensorweb3.pyto resolve addresses to names for displaying transaction histories or user profiles.
30M+
Monthly Active Users (MetaMask)
05
Cross-Chain Resolution Services
Services like Space ID and Chainlink CCIP enable reverse resolution across different blockchain ecosystems.
- Space ID: A universal name service network that provides a unified API to resolve addresses to names across multiple supported blockchains (BNB Chain, Arbitrum, etc.).
- Chainlink CCIP: While primarily for cross-chain messaging, its architecture can be used to build secure, cross-chain identity and resolution systems by verifying state across chains.
06
Developer Implementation Steps
To implement reverse resolution in an application, developers typically follow this flow:
- Check Support: Call
supportsInterface(0x5f5b857f)on the address's resolver to see if it supports reverse resolution. - Query Name: If supported, call the resolver's
name()function with the address. - Forward Verify: For security, perform a forward resolution on the returned name to ensure it points back to the original address, preventing spoofing.
- Cache Results: Cache the result to reduce RPC calls and improve performance.
ecosystem-usage
REVERSE RESOLUTION
Ecosystem Usage
Reverse resolution maps a blockchain address (like 0x...) to a human-readable name, enabling applications to display user-friendly identifiers instead of cryptographic hashes.
02
Decentralized Identity & Social Graphs
Acts as a foundational layer for decentralized identity (DID) systems. A resolved name can link to metadata profiles, social credentials, or attestations.
- Profile Association: Platforms like Lens Protocol or Farcaster can resolve an address to a
.lensor.fcastname to display user profiles. - Verifiable Credentials: The reverse-resolved name becomes a persistent identifier for reputation and on-chain activity.
04
Smart Contract Integration
Smart contracts can perform on-chain reverse resolution to verify identity or apply permissions.
- Access Control: A governance contract might check if a caller's address resolves to a specific
.daoname for voting rights. - NFT Metadata: An NFT collection can use the owner's reverse-resolved name for dynamic trait generation or personalized content.
- Standard Interface: The ENS Reverse Registrar provides a standard `EIP-181** for contracts to set and resolve reverse records.
05
Cross-Chain & Multi-Service Resolution
Extends functionality beyond a single blockchain or naming service through aggregators and resolution standards.
- Multi-Chain: Address on Polygon or Arbitrum can be resolved to a name registered on Ethereum mainnet via bridges and CCIP-Read.
- Service Agnostic: Resolvers like Unstoppable Domains or Space ID provide their own reverse records, with wallets often querying multiple services.
- Fallback Systems: Applications implement logic to try several resolution paths for the best result.
technical-details
REVERSE RESOLUTION
Technical Details: The ENS Example
This section details the mechanics of reverse resolution, a critical function that maps a blockchain address back to a human-readable name, using the Ethereum Name Service (ENS) as the canonical example.
Reverse resolution is the process of mapping a blockchain address, such as 0x1234...abcd, back to a human-readable domain name, like alice.eth. This is the inverse of the more common forward resolution, where a name is resolved to an address. In the context of the Ethereum Name Service (ENS), this is achieved through a dedicated, standardized resolver contract and a special domain, addr.reverse. The process allows wallets, explorers, and dApps to display familiar names instead of long hexadecimal strings, significantly improving user experience and reducing errors.
The technical implementation in ENS is governed by EIP-181. A user must first set a reverse record for their address by calling the setName() function on the official ReverseRegistrar contract. This action creates a record within the addr.reverse domain, where the subdomain is the address in lowercase hexadecimal format (e.g., 1234...abcd.addr.reverse). The resolver for this subdomain then stores the canonical name, such as alice.eth. Any application can then query this record via the name() function on the resolver to perform the reverse lookup.
A key distinction is that reverse resolution is opt-in and not automatically synchronized with forward resolution. Owning alice.eth does not automatically create a reverse record; the owner must explicitly configure it. Furthermore, the system is permissionless—anyone can set a reverse record for any address, but the record's validity is cryptographically verifiable. Applications should always perform a forward resolution check (resolving the returned name back to an address) to confirm the record's authenticity and prevent spoofing, ensuring the displayed name genuinely represents the address owner's intent.
DOMAIN NAME RESOLUTION
Reverse Resolution vs. Forward Resolution
A comparison of the two fundamental lookup directions in blockchain naming systems, such as ENS (Ethereum Name Service).
| Feature | Forward Resolution | Reverse Resolution |
|---|---|---|
Primary Query | Human-readable name (e.g., alice.eth) | On-chain address (e.g., 0x1234...) |
Primary Result | Resolves to a blockchain address or other resource (e.g., 0x1234...) | Resolves to a canonical name record (e.g., alice.eth) |
Core Function | Send assets to a name | Identify the name of a sender/contract |
On-Chain Record | Resolver contract pointed to by the name's registry | Special-purpose .addr.reverse domain owned by the address |
Standard Interface | ENS's | ENS's |
Common Use Case | User enters 'alice.eth' to send crypto | Wallet displays 'alice.eth' for an incoming transaction |
Lookup Initiator | Typically the sender/user | Typically the receiver/application (wallet, explorer) |
Registry Authority | Name owner sets the resolver and records | Address owner claims and sets the reverse record |
security-considerations
REVERSE RESOLUTION
Security Considerations
While reverse resolution maps a blockchain address to a human-readable name, it introduces unique security considerations distinct from standard name resolution.
01
Name Spoofing & Impersonation
A primary risk is name spoofing, where a malicious actor registers a name deceptively similar to a trusted entity. This can be used for phishing attacks or to misrepresent transaction origins.
- Example: Registering
paypa1.ethinstead ofpaypal.eth. - Mitigation: Users must verify the canonical name by performing a forward resolution (look up the name to get the address) and comparing it to the expected address.
02
Registry & Resolver Trust
Reverse resolution relies on the security of two smart contracts: the registry (e.g., ENS Registry) and the resolver set for the name. A compromised or poorly configured resolver can return incorrect or malicious data.
- Risk: If an attacker gains control of the resolver contract linked to a
.ethname, they can point reverse records to any address. - Best Practice: DApps should use well-audited, canonical resolvers and warn users about custom resolver contracts.
03
Cache Poisoning & Stale Data
Applications often cache reverse resolution results to improve performance. This introduces risks of cache poisoning (serving maliciously injected data) or serving stale data after a name has been transferred or updated.
- Consequence: A wallet might display an old, incorrect name for an address long after ownership has changed.
- Mitigation: Implement appropriate Time-To-Live (TTL) policies for cached records and provide manual refresh mechanisms.
04
Lack of Reverse Record Uniqueness
Unlike forward resolution (one name points to one address), reverse resolution is not unique. Multiple names can set their reverse record to the same address, and an address owner can change their preferred name at any time.
- Security Implication: An address's displayed name is a claim, not a verified identity. It should be treated as user-provided data, not a source of truth for authorization.
- Use Case: Suitable for user-friendly display, but insufficient for access control or definitive attribution.
05
Integration Vulnerabilities in Wallets & DApps
Wallets and decentralized applications (DApps) that integrate reverse resolution must handle edge cases securely to avoid UI deception or logical flaws.
- Common Pitfalls:
- Truncating long names in a way that hides spoofed characters.
- Failing to indicate when a name is a reverse record vs. a direct input.
- Using the reverse-resolved name as a primary key in databases or for permissions.
- Recommendation: Always display the underlying address alongside the resolved name for verification.
06
Metadata & Social Engineering
Reverse resolution often pulls in metadata like avatars or descriptions from the resolver. This enriched data can be weaponized for advanced social engineering.
- Attack Vector: An attacker could set a reverse record with a legitimate-looking name and an avatar impersonating a well-known project or individual.
- Defense: Treat all resolver-provided metadata as untrusted. Consider implementing visual indicators for verified profiles (where applicable) versus basic reverse records.
REVERSE RESOLUTION
Common Misconceptions
Reverse resolution is a critical but often misunderstood component of blockchain naming systems. This section clarifies the technical realities behind common assumptions about how on-chain data is linked to human-readable names.
No, reverse resolution is the opposite of a DNS lookup. A traditional DNS lookup resolves a human-readable domain name (like example.com) to a machine-readable IP address (like 93.184.216.34). Reverse resolution on a blockchain does the inverse: it maps a machine-readable address (like 0x742d35Cc6634C0532925a3b844Bc9e...) back to a human-readable name (like alice.eth). The process is fundamentally different because it queries a decentralized, on-chain registry (like an ENS resolver) rather than a centralized DNS server, and the mapping is stored as a smart contract record, not a traditional zone file.
REVERSE RESOLUTION
Frequently Asked Questions
Reverse resolution allows you to find the human-readable name associated with a blockchain address, flipping the standard lookup process. These questions cover its core concepts, use cases, and technical implementation.
Reverse resolution is the process of mapping a blockchain address (like 0x...) back to its associated human-readable domain name (like alice.eth). It works by querying a reverse resolver contract, which stores a canonical reference from an address to a name. This is the inverse of forward resolution, where a name is resolved to an address. The process typically involves:
- Querying a Registry: The system checks a designated reverse registry (e.g., the
.addr.reversedomain in ENS). - Resolving the Pointer: The registry returns the address of a resolver contract configured for that specific address.
- Fetching the Name: The resolver contract is then queried to return the canonical name record (like the
name()ortext()record) stored for that address.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall