docs(ens): say why the resolver announces ENSIP-10 and nothing else - #23
Merged
xgreenx merged 1 commit intoSep 7, 2026
Merged
Conversation
ERC-7996 is the id the ENS universal resolver reads as leave to call a
resolver directly instead of through the batch gateway. On that route it
raises the OffchainLookup again under its own address, so the {sender} a
client fills into the gateway URL is the universal resolver, and a gateway
that signs for the URL's address signs for the wrong target. The NatSpec on
supportsInterface now records this, and a test pins the absence of the id.
Assisted-by: Claude Fable 5.1
Signed-off-by: xgreenx <xgreenx9999@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #22 (
chore/ens-resolver-followups), which is stacked on #15. Docs and one test; no behaviour change.What this says
HandleResolverannounces ENSIP-10 and ERC-165 and nothing else. The NatSpec onsupportsInterfacenow says why the absence of ERC-7996 (0x582de3e7) is deliberate, and a test pins it so a future edit has to argue the point.Why it matters
ENS's
ResolverCaller(shared by today's mainnetUniversalResolverand by ENSv2'sDNSTLDResolver) picks one of two routes to a resolver:OffchainLookupis forwarded to a batch gateway as a request whosesenderis our resolver (ENSIP-21). The{sender}filled into the URL is us, so a gateway that signs for the address in the URL signs for the right target.{sender}becomes the universal resolver. A gateway signing for the URL then signs for the wrong target andresolveWithProofrefuses every answer.So announcing ERC-7996 without a gateway that signs for a configured resolver address breaks resolution outright. The note records the condition under which a future deployment may announce it, together with
eth.ens.resolver.extended.multicall.References: ENSIP-22, ENSIP-21, ResolverCaller.sol, CCIPReader.sol (the sender rewrite), DNSTLDResolver.sol (ENSv2 consults the v1 registry first, so this resolver and the
setResolverstep survive v2 unchanged).Observed
The Sepolia
handles.linkentry already points at aHandleResolver(0xd46181CAb629AEDA48406b462656513821De6775): ENSIP-10 true, ERC-7996 false, one URLhttp://127.0.0.1:8080/ens/{sender}/{data}.json. Consistent with this note; the gateway requirements themselves go in the design doc (libid-org/libid, stacked on #7).Verification