feat(ens): use Universal Resolver for ENS resolution#3822
Open
Dhaiwat10 wants to merge 1 commit intoethereum:mainfrom
Open
feat(ens): use Universal Resolver for ENS resolution#3822Dhaiwat10 wants to merge 1 commit intoethereum:mainfrom
Dhaiwat10 wants to merge 1 commit intoethereum:mainfrom
Conversation
Dhaiwat10
force-pushed
the
feat/universal-resolver
branch
2 times, most recently
from
9c3e554 to
4fdc20a
Compare
Use the ENS Universal Resolver (0xeEeEEEeE14D718C2B47D9923Deab1335E144EeEe) as the sole resolution path for all read operations. Per ENS docs, the UR is "the canonical entrypoint to ENS for name resolution." This fixes ENSv2 readiness by: - Eliminating the supportsInterface gate that blocked CCIP-Read/offchain resolution - Supporting DNS name resolution and cross-chain (L2) address lookups - Reducing RPC round-trips (single UR call vs registry→resolver→call) Deleted legacy code: _get_resolver, _resolve_legacy, _resolver_supports_interface, _validate_resolver_and_interface_id, _type_aware_resolver, UnsupportedFunction. Write operations unchanged — still use the registry directly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Dhaiwat10
force-pushed
the
feat/universal-resolver
branch
from
4fdc20a to
ac32e5e
Compare
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.
Hey! I'm Dhaiwat from the DevRel team at ENS Labs. We're working on getting libraries across the ecosystem ready for ENSv2.
What was wrong?
ENS read operations (
address,name,get_text,resolver) query the ENS Registry directly instead of using the Universal Resolver. The Universal Resolver (0xeEeEEEeE14D718C2B47D9923Deab1335E144EeEe) is the canonical entry point for ENS resolution on Ethereum Mainnet and is required for ENSv2 readiness. Once ENSv2 is live, libraries that don't use the Universal Resolver will resolve some names to incorrect or stale addresses.How was it fixed?
Updated all ENS read operations to use the Universal Resolver instead of querying the ENS Registry directly. Write operations (
setup_address,setup_name,set_text) are unchanged.UNIVERSAL_RESOLVER_ADDRconstantUNIVERSAL_RESOLVERABI withresolve(),reverse(), andfindResolver()functions_resolve(),address(),resolver(), andget_text()to call the Universal Resolver_get_resolver,_resolve_legacy,_resolver_supports_interface,_validate_resolver_and_interface_id,_type_aware_resolver)With this PR, web3.py goes from 3/9 to 6/9 on our official resolution-tests suite for libraries:
More details on ENSv2 readiness: https://docs.ens.domains/web/ensv2-readiness
Todo: