Summary: ENSIP-9 is worth cataloging not as a small ENS resolver upgrade, but as the lower layer that turns ENS from an Ethereum-only address book into a coin-typed naming interface for many chains. Its core move is to standardize addr(bytes32 node, uint coinType) -> bytes, using SLIP-44 coin types and chain-specific native binary encodings rather than human text strings. That design matters because it pushes multichain address formatting, checksum rules, and chain-specific script/address codecs into a shared resolver interface that wallets and apps can consume consistently. It is a useful comparison point for ENSIP-11, ENSIP-19, CAIP account naming, and wallet-auth subject standards because it exposes where canonical address interpretation really lives: in shared codec policy, coin-type registries, and resolver behavior rather than in the higher-level ENS UI.
What it does:
Extends ENS resolvers with addr(bytes32 node, uint coinType) so a single ENS name can resolve to addresses for many blockchains
Uses SLIP-44 coin types as the namespace for non-Ethereum address records
Standardizes how addresses are stored onchain as native binary data instead of user-facing text strings
Defines chain-specific encoding rules for common address families including Bitcoin scriptPubKeys, SegWit, EIP-55 / RSKIP-60 checksummed hex, Ripple address forms, CashAddr, and Bech32 variants
Recommends a parallel setter interface setAddr(bytes32 node, uint coinType, bytes calldata addr) and an AddressChanged event for updates
Preserves backwards compatibility by requiring ENSIP-1 addr(bytes32) behavior to stay aligned with addr(node, 60) for Ethereum
Key claims:
ENSIP-9 cleared the bar because it isolates the address-representation layer itself. Before reverse names, primary names, wallet login, or multichain identity UX, someone has to decide how non-Ethereum chain addresses are keyed, encoded, and retrieved from ENS.
The most important technical move is storing addresses in their native binary formats. The spec does not simply add more text fields; it standardizes a cross-chain resolver interface while leaving each chain’s textual conventions at the client edge.
That makes ENSIP-9 a meaningful control surface: whoever maintains coin-type conventions and codec implementations materially shapes what counts as the canonical address for a name on each chain.
The address-encoding section is analytically valuable because it shows ENS is not merely storing labels for chains. It is normalizing very different address grammars into one resolver abstraction, from Bitcoin scriptPubKeys to EVM hashes to Ripple’s distinct encodings.
The backwards-compatibility rule is also important. ENSIP-9 does not replace Ethereum-native ENS behavior; it redefines addr() as a special case of the broader multichain interface, which is why later standards like ENSIP-11 and ENSIP-19 can build on it cleanly.
ENSIP-9 belongs in the active corpus because it is the reusable substrate beneath ENS multichain address resolution. Without it, ENSIP-11’s chainId mapping and ENSIP-19’s multichain primary-name logic are much harder to express.
The strongest comparison questions for later work are: when does SLIP-44 registry dependence become a bottleneck, how much implementation power sits in shared codec libraries, and when should address naming be registry-driven versus algorithmic.
Whitepaper: No standalone ENSIP-9 whitepaper surfaced in this pass. The clearest primary materials were the official ENSIP-9 and ENSIP index pages, the related ENSIP-11 and ENSIP-19 docs for downstream context, and the ENS resolver / address-encoder implementation surfaces collected in ../../whitepapers/ensip-9-primary-sources-2026-05-13.md.