Reverse Resolution

Reverse resolution maps an address back to an ENS name (the "primary name"). ENSv1 already supports multi-chain reverse resolution via per-chain L2 Reverse Registrars with signature-based claims (ENSIP-19). ENSv2 refines the signature-based claim system and integrates reverse resolution into the v2 registry hierarchy.

At Launch

At launch, the reverse namespace (addr.reverse, default.reverse) stays on v1 infrastructure. The v2 ReverseRegistry holds entries for these names, but resolution is handled by v1 contracts. Existing primary names continue to work without any user action.

addr.reverse: Registered in the ReverseRegistry with ENSV1Resolver as its resolver. This mirrors resolution through the v1 ENS registry, so existing v1 reverse records are automatically visible in v2. Users update their reverse record via the v1 ReverseRegistrar.claimForAddr().

default.reverse: Uses the v1 DefaultReverseRegistrar, which stores primary names directly and resolves them via wildcard resolution on-contract. Users set their name via DefaultReverseRegistrar.setNameForAddr().

Contract Account Adapters

Contract accounts (multisigs, smart wallets, protocol contracts) can't always interact with the v1 reverse registrars directly, because those contracts authorize via msg.sender. Two adapter contracts, added as controllers on the v1 registrars, forward reverse-record updates on behalf of a contract:

Both adapters authorize the caller with the same "namer" check: the caller must be the account itself, the account's Ownable owner, or approved by the account's own IContractNamer.isContractNamer() implementation.

Migration to v2-native

The reverse namespace will be migrated to v2-native infrastructure post-launch. The same migration pattern applies to both testnet and mainnet. The full multi-chain reverse resolution system described below will be rolled out as L2 partner integrations are completed.

Multi-Chain Reverse Resolution (Upcoming)

ENSv2 introduces a new L2ReverseRegistrar designed to be deployed on each chain individually. Each deployment stores the mapping from addresses to their primary names for that chain. The Universal Resolver V2 resolves reverse lookups via the inherited reverse(lookupAddress, coinType) function, which queries the appropriate reverse registrar based on the coin type.

Setting a Primary Name

The L2ReverseRegistrar provides four methods for setting a primary name, covering different authorization models:

Signature-Based Claims

For gasless or cross-chain primary name claims, the signature methods accept a NameClaim struct:

struct NameClaim {
    string name;       // The ENS name to set as primary
    address addr;      // The address to set it for
    uint256[] chainIds; // Chain IDs where this claim applies
    uint256 signedAt;  // Timestamp for replay protection
}

The chainIds array allows a single signature to set the primary name across multiple chains simultaneously. Chain IDs must be in strictly ascending order.

Signature Format

Signatures use ERC-191 plaintext format:

You are setting your ENS primary name to:
{name}
 
Address: {address}
Chains: {chainList}
Signed At: {signedAt}

Where {chainList} is a comma-separated list of chain IDs and {signedAt} is an ISO 8601 UTC datetime string.

For contracts (via setNameForContractWithSignature), the format includes an additional Owner field:

You are setting the ENS primary name for a contract you own to:
{name}
 
Contract Address: {address}
Owner: {owner}
Chains: {chainList}
Signed At: {signedAt}

Replay Protection

Signature-based methods use an inception timestamp system. Each address has a stored inception timestamp on-chain. For a signature to be valid:

1. The signature's signedAt must be strictly greater than the current inception for that address
2. The signedAt must not be in the future (signedAt <= block.timestamp)

When a valid signature is used, the inception is updated to the signedAt value. This ensures each signature can only be used once per chain, and newer signatures always supersede older ones. Query the current inception via inceptionOf(address).

Contract Name Sync

The L2ReverseRegistrar also supports syncName(addr) for contracts that implement the IContractName interface. This allows anyone to sync a contract's primary name without requiring a signature, using the name the contract itself declares.

Contracts