Kraken
Correctly Resolve Deposit Addresses
Ensure your app correctly resolves which address and chain a deposit to an ENS name should be sent to.
Pending
Kraken
Ensure your app correctly resolves which address and chain a deposit to an ENS name should be sent to.
Pending
ENSAwards score
Pending
When an app needs its users to identify a particular address on a particular chain where an action should be taken (such as a transfer or deposit), ENS offers the possibility of a better user experience. Instead of forcing users to enter a long string of hexadecimal digits, with ENS, users can have the option of entering a simple name such as vitalik.eth. ENS can then be used to translate this input name into the relevant deposit address, such as0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045. This process of determining the deposit address for a name is an example of what is called "resolution".
This best practice checks that your app correctly resolves ENS names to the correct address and chain for different contexts.
The simplest way to get this right—and to continuously and automatically stay up to date with all ENS best practices even as ENS keeps evolving—is to use the ENS Omnigraph API (powered by ENSNode) which handles the implementation details of ENS resolution for you. The implementation recommendations below cover how your engineering team can adopt it, or other supported options.
Apps that fail to correctly implement ENS resolution fail their users and erode trust in important ways. Failure to integrate ENS at all damages the user experience of the app and exposes users to key risks such as address poisoning attacks.
If ENS resolution is integrated, but not according to all ENS best practices, then it can cause big issues. For example, deposits may silently be sent to the wrong address and be irrecoverably lost. Or only a subset of ENS names might be properly supported which damages the network effects and market distribution of ENS.
The baseline test for supporting ENS resolution of deposit addresses is to test with an onchain direct subname of .eth (such as vitalik.eth) where the name is input in fully normalized form and the context for resolving the deposit address is on the Ethereum Mainnet chain.
Contributions are open
Submit result on GitHubThis variation of the baseline test changes the input name to Ξthereum.eth.
This acceptance test verifies correct implementation of ENS name normalization and input validation rules. This name is valid for input as an ENS name. It is not ENS normalized but it is ENS normalizable.
Contributions are open
Submit result on GitHubThis variation of the baseline test changes the input name to jesse.base.eth.
This acceptance test verifies correct implementation of CCIP-read for a subname nested beneath .eth.
Contributions are open
Submit result on GitHubThis variation of the baseline test changes the input name to dperri.com.
This acceptance test verifies correct implementation of CCIP-read for DNS names that have not been imported onchain but are still valid ENS names.
Contributions are open
Submit result on GitHubThis variation of the baseline test makes two changes: (1) the input name changes to lightkeeper.eth and (2) the context of the resolution changes from Ethereum Mainnet to another EVM chain (the Base chain that's operated by Coinbase).
This acceptance test verifies correct implementation of resolving the address for a name in the context of different EVM chains.
Contributions are open
Submit result on GitHubThis variation of the baseline test makes two changes: (1) the input name changes to gregskril.eth and (2) the context of the resolution changes from Ethereum Mainnet to the non-EVM chain Bitcoin.
This acceptance test verifies correct implementation of resolving the address for a name in the context of a non-EVM chain such as Bitcoin.
Contributions are open
Submit result on GitHubThis variation of the baseline test makes two changes: (1) the input name changes to gregskril.eth and (2) the context of the resolution changes from Ethereum Mainnet to the non-EVM chain Solana.
This acceptance test verifies correct implementation of resolving the address for a name in the context of a non-EVM chain such as Solana.
Contributions are open
Submit result on GitHubThis variation of the baseline test makes two changes: (1) the input name changes to zissou.eth and (2) the context of the resolution changes from Ethereum Mainnet to the EVM chain Base.
This acceptance test verifies correct implementation of resolving the address for a name on an EVM chain that is not formatted as a valid EVM address (not a 20-byte hex value), instead resolving to (invalid address).
Contributions are open
Submit result on GitHubThere are a few ways to make sure your app's ENS resolution follows all best practices.
1. Take full responsibility yourself.
One option is to take the full responsibility for implementing all of these details correctly yourself and continuously and rigorously testing your app for continued compliance.
2. Use the ENS Omnigraph API (recommended).
Another, more highly recommended option is to simply perform your ENS resolutions through the ENS Omnigraph API (powered by ENSNode).
Fetch your ENS data through the ENS Omnigraph API and everything just works. It's a single typed GraphQL API over both ENSv1 and ENSv2 for every chain and offchain names too. It also handles the indexed ENS data your app reads (e.g. the names an address owns, profiles, histories, etc.), with resolutions accelerated by Protocol Acceleration. Drop it in with enssdk (TypeScript) or enskit (React).
App
Category
ENS Resolution
ENS best practice
Correctly Resolve Deposit AddressesAcceptance test results
PendingAll benchmarks on ENSAwards are open for public contribution.
All benchmarks on ENSAwards are open for public contribution.
ENSAwards score
Pending
Founded in 2022, Namehash Labs is dedicated to developing open source infrastructure that helps the Ethereum Name Service (ENS) Protocol grow.