ENSIP-11 primary sources — 2026-05-13

What I reviewed

• ENS documentation:
  • https://docs.ens.domains/ensip/11
  • https://docs.ens.domains/ensip/
  • https://docs.ens.domains/ensip/9
  • https://docs.ens.domains/ensip/19
• ENS implementation repo / library surface:
  • https://github.com/ensdomains/ensips
  • https://github.com/ensdomains/address-encoder
  • https://raw.githubusercontent.com/ensdomains/address-encoder/master/README.md

Key takeaways from primary sources

• ENSIP-11 solves a real naming bottleneck inside multichain Ethereum: ENSIP-9 depended on SLIP-44 coin-type assignments, but EVM-compatible chains were proliferating faster than that registry model made sense for.
• The core mechanism is elegant and lower-layer enough to matter: reserve the high-bit range where SLIP-44 has no entries, and define EVM-chain coin types as 0x80000000 | chainId.
• The spec is valuable because it does not merely add more identifiers; it turns chain-id-to-coin-type conversion into a deterministic rule that clients, wallets, resolvers, and libraries can all share.
• Backwards compatibility is a meaningful part of the design. Older EVM-like coin types are treated as legacy/read-only, while AVAX and RSK stay as explicit exceptions because the generic EVM assumptions do not fully apply.
• ENSIP-19 makes the downstream significance clearer than ENSIP-11 alone: once coin types and chain IDs can be mapped cleanly, multichain primary names and reverse resolution become more standardizable across the Ethereum ecosystem.
• The @ensdomains/address-encoder README is the best implementation-facing proof that ENSIP-11 is not just a document. It bakes the mapping into reusable address codec tooling, which means downstream apps can inherit the rule by default.

Specific source signals worth retaining

• ENSIP-11 is the best direct source for the motivation, the deterministic bitwise mapping, the exception list, and the backwards-compatibility policy.
• The ENSIP index page is the best source for status/context, showing ENSIP-11 as a Final proposal in a broader family that includes ENSIP-9 and ENSIP-19.
• ENSIP-9 is the best source for the earlier coinType / address-encoding baseline that ENSIP-11 amends.
• ENSIP-19 is the best source for why ENSIP-11 matters downstream: reverse resolution and primary-name logic on multichain Ethereum explicitly depend on that mapping layer.
• The address-encoder README is the best concise source for practical library support and for the claim that EVM chains can be specified either by SLIP-44 coin type or by 0x80000000 | chainId.

Why this entry belongs in the corpus

• It adds a narrow but durable standards-layer beneath ENS UX, multichain identity, and wallet interoperability.
• It helps separate subject/address naming from higher-layer login, session, and primary-name UX.
• The durable insight is that multichain ecosystems do not only need more apps and wallets; they also need stable shared rules for how addresses and chains are named when centralized registries stop scaling cleanly.