Summary: ENSIP-10 is worth cataloging not as a mere ENS convenience feature, but as the lower-layer protocol change that lets unresolved subdomains inherit resolution logic from a parent name without requiring per-subdomain registry writes. Its core mechanism is a parent-walk resolver search combined with an optional resolve(bytes name, bytes data) interface: if a name has no exact resolver, clients climb toward the parent until they find one, then ask that resolver to answer for the original full name. That makes ENSIP-10 a useful comparison point for ENSIP-1, ENSIP-19, ERC-3668, and wallet identity middleware because it exposes where practical naming power sits once wildcard subdomains, late-bound address derivation, and client resolver-selection rules become their own control surface.
What it does:
Extends ENS resolution so clients can walk up parent labels until they find a resolver instead of failing immediately on an unset subdomain
Standardizes an optional ExtendedResolver.resolve(bytes name, bytes data) entrypoint with ERC-165 interface ID 0x9061b923
Requires clients to pass the original full DNS-encoded name into resolve, even when the resolver was discovered on a parent node
Preserves exact-match override behavior because any subdomain with its own resolver stops the parent walk and supersedes parent wildcard logic
Enables dynamic subdomain patterns such as counterfactual-address naming, fallback-address naming, and label-aware resolver logic without modifying the ENS registry contract
Forces a compatibility boundary where legacy methods like addr() may only be called when the resolver is set directly on the exact name being resolved
Key claims:
ENSIP-10 cleared the bar because it makes wildcard name resolution a distinct protocol layer rather than an implementation trick inside one resolver product.
The most durable mechanism insight is the split between resolver discovery and record resolution. ENSIP-10 lets parent nodes supply resolver logic for child names, but still requires the original child name to be the subject of resolution.
The resolve(bytes name, bytes data) interface matters because it gives resolvers access to plaintext labels rather than only a namehash. That is what makes patterns like NFT-ID-based subdomains or deterministic per-label addressing analytically possible.
The spec is unusually careful about compatibility. Exact-name resolvers still win, existing registry and resolver contracts do not need to change, and legacy clients merely fail on wildcard records rather than misreading standard exact-match records.
The prohibition on calling legacy methods during wildcard resolution is not a small implementation detail; it is a real safety boundary that prevents parent wildcard resolvers from being treated like exact-match resolvers by older clients.
ENSIP-10 also surfaces an important user-risk tradeoff: arbitrary wildcard subdomains make large-scale onboarding easier, but they also increase typo-risk and the chance of funds being routed to unintended recipients if client validation is weak.
ENSIP-10 belongs in the active corpus because it preserves a reusable distinction between registry writes, resolver discovery policy, and resolver-side name interpretation. That distinction would be lost if it were filed only as generic ENS scalability.
Whitepaper: No standalone ENSIP-10 whitepaper surfaced in this pass. The clearest primary materials were the official ENSIP-10 docs, the ENSIPs repository text, and the ENSIP repository README collected in ../../whitepapers/ensip-10-primary-sources-2026-05-13.md.