ENSIP-19

  • Name: ENSIP-19 (Multichain Primary Names)
  • URL: https://docs.ens.domains/ensip/19
  • Category: multichain ENS reverse-resolution standard / primary-name verification layer / cross-chain identity-defaults policy
  • Summary: ENSIP-19 is worth cataloging not as a cosmetic ENS feature, but as the layer that standardizes how a blockchain address proves which ENS name should be displayed for it across multichain Ethereum. Its core mechanism is a two-phase primary-name check: compute a coin-type-specific reverse name from the address, resolve a candidate name from that reverse namespace, and then verify the candidate by forward-resolving it back to the same address bytes. Around that verification loop, ENSIP-19 adds a more important policy split: default EVM-wide names, chain-specific names, and rollup-verifiable reverse registrars become separate layers instead of one implicit “mainnet primary name” shortcut. That makes it a useful comparison point for ENSIP-3, ENSIP-9, ENSIP-11, CAIP account naming, and wallet identity middleware because it exposes where practical identity authority sits once one account may have different addresses and deployment semantics across chains.
  • What it does:
    • Standardizes reverse resolution and verified primary-name resolution for all ENS coin types
    • Defines a two-phase algorithm where a reverse record yields a candidate name and a forward lookup must resolve that name back to the same address bytes before the name is trusted
    • Introduces coin-type-aware reverse namespaces such as addr.reverse, default.reverse, and [coinTypeAsHex].reverse
    • Uses ENSIP-11 chainId-to-coinType mapping to distinguish default EVM-wide names from chain-specific names across rollups and other EVM chains
    • Defines a registry-independent registrar model and ENSIP-10 wildcard-resolution flow for default and chain-specific multichain reverse records
    • Adds a default-address fallback rule for EVM chains and explicitly deprecates old client assumptions that the mainnet address or mainnet primary name should silently act as the default everywhere
  • Key claims:
    • ENSIP-19 cleared the bar because it isolates identity-display policy as a real protocol layer. It is not just about prettier wallet UX; it formalizes how reverse lookup, forward verification, and multichain defaults interact when ENS names span many chains.
    • The two-phase verification rule is the most durable mechanism insight. Reverse records alone do not prove ownership of a displayed name; ENSIP-19 requires the candidate name to resolve back to the same address bytes, making primary-name display a verified round trip.
    • The distinction between default.reverse and chain-specific reverse namespaces is analytically important because it turns which name should wallets show? into an explicit policy question instead of an undocumented mainnet convention.
    • ENSIP-19 is especially valuable because it recognizes that modern Ethereum identity is no longer one-address-one-name. EOAs may reuse the same address across chains, while smart contract accounts may not, so the spec separates Ethereum-wide defaults from chain-local primary names.
    • The multichain-Ethereum section reveals a new operational control surface: wildcard resolvers, per-chain registrars, and proof/verification paths for chains that post state to L1. In practice, the reverse namespace becomes an interoperability and verification layer, not just a storage slot.
    • The deprecation guidance matters too. ENSIP-19 explicitly tells clients to stop assuming mainnet names or addresses are universal defaults, which is a meaningful governance and safety shift for wallets operating across rollups and smart-account schemes.
    • ENSIP-19 belongs in the active corpus because it preserves a reusable distinction between address resolution, reverse naming, and identity-default policy. That separation would be lost if it were filed as generic ENS UX.
    • The strongest comparison questions for later work are: when should clients display default EVM-wide names versus chain-specific names, how much trust sits in wildcard resolver infrastructure, and whether multichain primary names decentralize identity or just re-center it in resolver and registrar defaults.
  • Whitepaper: No standalone ENSIP-19 whitepaper surfaced in this pass. The clearest primary materials were the official ENSIP-19 and ENSIP index pages, the related ENSIP-3 / ENSIP-9 / ENSIP-10 / ENSIP-11 docs for mechanism context, and the ENS implementation surfaces collected in ../../whitepapers/ensip-19-primary-sources-2026-05-13.md.
  • Sources:

Internal linkages

  • Keep this one anchored to the tight ENS naming stack beneath it.
  • Best reads: ensip-9, ensip-10, and ensip-11.
  • Reusable lens: the real leverage is in display-default policy and verification rules, not in the cosmetic name string alone.
  • Last reviewed: 2026-05-13 UTC