Resloving Names
Last updated
Last updated
The EVMNS namespace includes ".evm" names, which are native to EVMNS. As the DNS suffix namespace expands over time, a hardcoded list of name suffixes for recognizing EVMNS names will frequently become outdated, resulting in your application not recognizing all valid EVMNS names. To ensure future-proof integration of EVMNS, the correct approach treats any dot-separated name as a potential EVMNS name and attempts a lookup accordingly.
Names can have many types of data associated with them; the most common is cryptocurrency addresses. EVMNS supports storing and resolving the addresses of any arbitrary blockchain.
Resolving a name to an EOS-EVM address using a library is simple:
Resolution without a library is a three step process:
Normalize and hash the name - see name processing for details.
Call resolver()
on the EVMNS registry, passing in the output of step 1. This returns the address of the resolver responsible for the name.
Using the , call addr()
on the resolver address returned in step 2, passing in the hashed name calculated in step 1.
Resolution support for the addresses of other blockchains is implemented with an additional overload on addr()
. To resolve a non-Ethereum address, supply both the namehash and the chain ID of the cryptocurrency whose address you want to resolve. For example, to resolve a Bitcoin address, you would call addr(hash, 0)
. Note that the returned address will be in binary representation, and so will need decoding to a text-format address.
If you are resolving addr() records, you MUST treat a return value from the resolver of 0x00…00 as that record being unset. Failing to do so could result in users accidentally sending funds to the null address if they have configured a resolver in EVMNS, but not set the resolver record!
contenthash
is used to store IPFS and Swarm content hashes, which permit resolving EVMNS addresses to distributed content (eg, websites) hosted on these distributed networks. content-hash javascript library provides a convenient way to encode/decode these hashes.
Note for ipns: For security reasons, the encoding of ipns is only allowed for libp2p-key
codec. Decoding with other formats will show a deprecation warning.
While some libraries allow you to query cryptocurrency addresses via their symbol (e.g.: BTC
), others do not have the built-in support, and you have to call via each coin id (e.g.: 0
for BTC
, 16
for `ETH). For Javascript/Typescript, we have @evmnsdomains/address-encoder library that allows you to convert
To save storage space as well as prevent users from setting wrong token address, the library has encoder
and decoder
For cryptocurrency addresses and text records, you need to know the coin type or key names to get the value.
For example
will return the following result
While 'regular' resolution involves mapping from a name to an address, reverse resolution maps from an address back to a name. EVMNS supports reverse resolution to allow applications to display EVMNS names in place of hexadecimal addresses.
Reverse resolution is accomplished via the special purpose domain addr.reverse and the resolver function name()
. addr.reverse is owned by a special purpose registrar contract that allocates subdomains to the owner of the matching address - for instance, the address 0x314159265dd8dbb310642f98f50c066173c1259b may claim the name 314159265dd8dbb310642f98f50c066173c1259b.addr.reverse, and configure a resolver and records on it. The resolver in turn supports the name()
function, which returns the name associated with that address.
EVMNS does not enforce the accuracy of reverse records - for instance, anyone may claim that the name for their address is 'alice.evm'. To be certain that the claim is accurate, you must always perform a forward resolution for the returned name and check it matches the original address.
Most libraries provide functionality for doing reverse resolution:
// setResolver
ENSRegistry->setResolver(bytes32 namehash,address resolver)
// name
PublicSolver->name(bytes32 hashname)
Reverse resolution without a library follows the same pattern as forward resolution: Get the resolver for 1234....addr.reverse
(where 1234... is the address you want to reverse-resolve), and call the name()
function on that resolver. Then, perform a forward resolution to verify the record is accurate.
If you need to process many addresses (eg: showing reverse record of transaction histories), resolving both reverse and forward resolution for each item may not be practical. We have a separate smart contract called ReverseRecords
which allows you to lookup multiple names in one function call.
Make sure to compare that the returned names match with the normalised names to prevent from as well as people simply using capital letters.