Summary: ENSIP-11 is worth cataloging not as a minor ENS housekeeping proposal, but as a lower-layer compatibility rule for multichain Ethereum naming. Its core move is to stop depending on SLIP-44 assignments for every EVM chain and instead reserve a high-bit coin-type range where EVM-compatible chain IDs can be derived algorithmically via 0x80000000 | chainId. That gives ENS, wallets, resolvers, and downstream standards a stable way to represent EVM-chain addresses inside ENS without waiting for per-chain manual registration. It is a useful comparison point for CAIP naming standards, ENSIP-9, ENSIP-19, and wallet-auth subject standards because it exposes a narrow but important control surface: who defines canonical chain/address identifiers when the ecosystem expands faster than centralized registries do.
What it does:
Extends ENSIP-9 so ENS resolvers can represent EVM-compatible chain addresses without requiring new SLIP-44 registrations for every chain
Reserves the high-bit coin-type range and defines a deterministic mapping from EVM chain IDs to ENS coin types using 0x80000000 | chainId
Defines the reverse mapping from ENS coin type back to EVM chain ID for clients, wallets, and tooling
Keeps exceptions explicit for chains like AVAX and RSK where address-format behavior differs from the generic EVM pattern
Marks previously allocated EVM-like coin types as legacy/read-only for backward compatibility rather than pretending they never existed
Provides an implementation path through ENS documentation and the @ensdomains/address-encoder library used by tooling
Key claims:
ENSIP-11 cleared the bar because it isolates a genuinely reusable lower layer: multichain Ethereum naming depends on canonical identifier derivation long before any wallet-login, primary-name, or offchain-resolution UX begins.
The specification explicitly says ENSIP-9’s reliance on SLIP-44 became redundant for EVM-compatible chains because most of them share Ethereum-style address encoding. ENSIP-11’s answer is to derive coin types from chain IDs instead of waiting for manual registry expansion.
The reserved most-significant-bit range is the key mechanism insight. By using a range where no SLIP-44 coin types exist, ENSIP-11 creates room for algorithmic EVM-chain address naming without colliding with non-EVM coin types.
The spec is also useful because it is candid about exceptions and backwards compatibility. AVAX and RSK are kept outside the generic rule, and older EVM-compatible coin types are deprecated rather than silently remapped.
The strongest reason to keep ENSIP-11 in the corpus is the downstream effect visible in ENSIP-19: once chain IDs can be converted to coin types deterministically, multichain primary names and reverse resolution become much easier to standardize.
The address-encoder repository matters because it turns the proposal into practical ecosystem plumbing. Once the mapping lives in a shared codec library, wallets and applications inherit the naming rule as implementation default, not just as a document.
Whitepaper: No standalone ENSIP-11 whitepaper surfaced in this pass. The clearest primary materials were the official ENSIP-11 and ENSIP index pages, the related ENSIP-9 and ENSIP-19 docs for context, and the @ensdomains/address-encoder README collected in ../../whitepapers/ensip-11-primary-sources-2026-05-13.md.