Resolving Names
The PNS namespace includes both .pls names (which are native to PNS) and DNS names imported into PNS. Because the DNS suffix namespace expands over time, a hardcoded list of name suffixes for recognizing PNS names will regularly be out of date, leading to your application not recognizing all valid PNS names. To remain future-proof, a correct integration of PNS treats any dot-separated name as a potential PNS name and will attempt a look-up.
Looking up cryptocurrency addresses
Names can have many types of data associated with them; the most common is cryptocurrency addresses. PNS supports storing and resolving the addresses of any arbitrary blockchain.
Resolving a name to an Ethereum address using a library is simple:
Resolution without a library is a three step process:
Normalise and hash the name - see name processing for details.
Call
resolver()
on the PNS registry, passing in the output of step 1. This returns the address of the resolver responsible for the name.Using the resolver interface, 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-PulseChain address, supply both the namehash and the SLIP44 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; for details, see EIP 2304.
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 PNS, but not set the resolver record!
Looking up other resources
PNS supports many types of resources besides PulseChain addresses, including other cryptocurrency addresses, content hashes (hashes for IPFS, Skynet, and Swarm, and Tor .onion addresses), contract interfaces (ABIs), and text-based metadata. The process for looking these up varies from library to library; for specific details see your chosen library's documentation.
Resolving these content types without a library follows the same 3-step process detailed above; simply call the relevant method on the resolver in step 3 instead of addr()
.
Encoding and decoding contenthash
contenthash
is used to store IPFS and Swarm content hashes, which permit resolving PNS 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.
Coin type and encoding/decoding
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
, 369 for `PLS). For Javascript/Typescript, we have @pnsdomains/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
Listing cryptocurrency addresses and text records
For cryptocurrency addresses and text records, you need to know the coin type or key names to get the value. If you want to list down all the cryptocurrency addresses and text records the user has set, you have to either retrieve the information from Event
or query via PNS subgraph.
For example
will return the following result
Reverse Resolution
While 'regular' resolution involves mapping from a name to an address, reverse resolution maps from an address back to a name. PNS supports reverse resolution to allow applications to display PNS 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.
PNS does not enforce the accuracy of reverse records - for instance, anyone may claim that the name for their address is 'alice.pls'. 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:
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 seperate 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 homograph attack as well as people simply using capital letters.
Last updated