Skip to main content
The Reverse Registrar is responsible for managing reverse resolution via the .addr.reverse special-purpose TLD. Reverse resolution allows ENS names to be associated with Ethereum addresses, enabling applications to display human-readable names instead of addresses.

​
What is Reverse Resolution?

Reverse resolution is the process of mapping an Ethereum address back to an ENS name. While standard ENS resolution maps names to addresses (forward resolution), reverse resolution does the opposite - it allows an address to specify which ENS name should be displayed when the address is encountered.

​
The .addr.reverse TLD

The .addr.reverse TLD is a special-purpose top-level domain in ENS used exclusively for reverse records. Each Ethereum address has a corresponding reverse record at <address>.addr.reverse. The reverse node is computed as: 
keccak256(ADDR_REVERSE_NODE, sha3HexAddress(address))
Where ADDR_REVERSE_NODE is the namehash of addr.reverse: 
0x91d1777781884d03a6757a803996e38de2a42967fb37eeaca72729271025a9e2

​
Reverse Registrar Implementations

ENS provides multiple implementations of reverse registrars for different use cases:

​
ReverseRegistrar (L1)

The primary reverse registrar deployed on Ethereum mainnet and L1 networks. It manages reverse records in the ENS registry and provides:
  • Claiming reverse records with custom resolvers
  • Setting names for reverse records
  • Authorization controls for managing reverse records on behalf of other addresses
  • Controller and Ownable-based permissions
See ReverseRegistrar for details.

​
L2ReverseRegistrar

A specialized reverse registrar designed for Layer 2 networks that combines resolver and registrar functionality. Key features include:
  • Standalone operation without requiring the ENS registry
  • Signature-based name setting for gasless transactions
  • Multi-chain signature support using unified validator addresses
  • Support for both EOA and contract-owned reverse records
See L2ReverseRegistrar for details.

​
DefaultReverseRegistrar

A simplified reverse registrar that provides basic reverse resolution functionality with signature support. It’s designed as a lightweight implementation for specific use cases.

​
Use Cases

​
Setting Your Primary Name

The most common use case is setting a “primary name” - the ENS name that should be displayed for your address: 
// On L1
reverseRegistrar.setName("alice.eth");

// On L2
l2ReverseRegistrar.setName("alice.eth");

​
Gasless Name Setting (L2)

On L2 networks, users can sign a message off-chain and have someone else submit the transaction: 
l2ReverseRegistrar.setNameForAddrWithSignature(
    addr,
    signatureExpiry,
    "alice.eth",
    [coinType],
    signature
);

​
Contract Reverse Records

Contracts that implement Ownable can have their reverse records set by their owner: 
// L2 example with signature
l2ReverseRegistrar.setNameForOwnableWithSignature(
    contractAddr,
    owner,
    signatureExpiry,
    "my-contract.eth",
    [coinType],
    signature
);

​
Authorization Models

​
L1 Authorization

On L1, the ReverseRegistrar supports multiple authorization methods:
  1. Direct ownership - The address owner can set their own reverse record
  2. ENS approval - Addresses approved via setApprovalForAll() in the ENS registry
  3. Controllers - Addresses with controller privileges
  4. Contract ownership - Owners of Ownable contracts can manage the contract’s reverse record

​
L2 Authorization

On L2, the L2ReverseRegistrar provides:
  1. Direct calls - Address owners calling directly
  2. Signature-based - EIP-191 signatures for EOA addresses
  3. Ownable contracts - Contract owners via signature with ERC-1271/ERC-6492 validation

​
Multi-Chain Deployment

The L2ReverseRegistrar is designed for consistent deployment across multiple L2 networks using the same contract address. This enables:
  • Unified signatures - One signature can work across multiple L2s
  • Consistent addressing - The validator address remains the same
  • Simplified integration - DApps can use the same interface across chains
Deployment is managed through Safe multisigs and CREATE3 contracts:
  • Testnet Safe: 0x343431e9CEb7C19cC8d3eA0EE231bfF82B584910
  • Mainnet Safe: 0x353530FE74098903728Ddb66Ecdb70f52e568eC1

​
Validator Addresses

For signature-based operations, the validator address is included in the signature per EIP-191:
  • Mainnet: 0xa4a5CaA360A81461158C96f2Dbad8944411CF3fd
  • Testnet: 0xAe91c512BC1da8B00cd33dd9D9C734069e6E0fcd

Build docs developers (and LLMs) love

Get started for freeTalk to us