]> D3 Global Inc

shay@d3.com

General Internet Engineering Task Force Web3 Wallet DNS Mapping This document proposes an implementation standard for mapping wallets to domain names using the new WALLET RRType, allowing for TXT record fallback while the WALLET RRType propagates through DNS providers. The goal is to provide a secure and scalable and unbiased way to associate wallets with domain names, enabling seamless lookup as well as suggesting required authentication mechanism. The proposal relies on DNSSEC or security successors to ensure trust and security.

Introduction There is fragmentation in the mapping of Web3 Wallets to Domain Names . This document puts forth an implementation standard to map Web3 Wallet addresses to Domain Names, as well as investigates the associated security and technical concerns. As the use of digital wallets and online services grows, the need for a standardized way to lookup wallet addresses in an human readable format becomes increasingly important. This proposal aims to provide a solution that is easy to implement, scalable, unbiased, standardized and secure. The proposed notational implementation involves using the DNS WALLET RRtype to map a domain name on the Global DNS system to wallet address information. The WALLET record will contain a object that maps the wallet address to a registered Namespace and the registered coin type token or . This implementation will handle multiple wallet addresses and chains, defaults, as well as defining a heirarchy to deterministicly be able to find the appropriate wallet address. It is assumed that the record will be part of a DNSSEC signed zonefile or its security successors, and that users of this service will verify the signatures to ensure that the record has been returned without alteration in flight. This implementation proposal is evolutionary to the the description in because it defines standards for coin names, defaults, and conditions for rejection, in order to have consistant usages. We also propose a fallback TXT record "_w3addr" which will be a backup for the WALLET RRtype and CAN duplicate the WALLET RRtype entries. This is intended to be a temporary measure while DNS Provider's UIs support this RRType .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document will refer to Domain Name terminology .

Domain to Wallet Mapping

Record Format The WALLET or TXT record SHALL have the following format:

@

is the address

IN

is the class of the record

WALLET / TXT

is the type of the record

namespace:reference:address1

is the value of the record

Grammar for the record in EBNF format

item

represents a namespace-reference-address tuple

namespace

covers a class of similar blockchains such as "Solana" or "eip155" specified by Chain Agnostic Namespaces . This is NOT case sensitive.

coin_name

represents the Symbol of a Coin Type represented in . This is NOT case sensitive.

reference

a way to identify a blockchain within a namespace. As an example this would be chain ID within eip155 ecosystem as referenced by . This is NOT case sensitive.

address

represents the public wallet address associated with a coin (e.g., "0xabcdefg", "0x12345", etc). This CAN be case sensitive as required by the wallet addressing scheme

This grammar can be used to parse the input string and extract the chain identifier and addresses.

Example Suppose a user wants to map their wallet with the public keys to the domain "example.com" using the registered coin type tokens BTC, SOL and and Ethereum mainnet chain id. The WALLET record in the zone would be:

TXT Record Example Suppose a user wants to map their wallet with the public keys to the domain "example.com" using the registered coin type tokens BTC, SOL and Ethereum mainnet chain id using a TXT record. The TXT record in the zone would be:

Multiple Records To support multiple coins, multiple coin:address pairs will each be represented by their own WALLET record. There is no guarantees on ordering the records so overlapping records MAY be ordered at the resolver's discretion. In the event of duplicate coin types it is RECOMMENDED that multiple records be returned deduplicated for identical addresses.

Implementation Wallet resolver implementations of this RFC SHALL:

1. Support the creation and retrieval of WALLET records for any given level of the DNS system.
2. Validate the records as being properly signed by DNSSEC or its successors.
3. Provide the wallet's address for a human readable domain name.
4. Provide an authoritative NXADDR if no address can be found.

Security Considerations To ensure the security of the mapping, the following measures will be taken:

1. The WALLET RRtype record SHALL BE stored in a secure location, such as a DNSSEC-signed zone.
2. The implementation SHALL validate the DNSSEC record or its IETF approved successors.
3. The wallet record SHALL be protected from replay attacks via DNSSEC time invalidation (or approved successors).

The WALLET RRtype might not be available throughout entire end to end DNS infrastructure. In the event that DNSSEC is not supported end to end, a wallet resolver MUST indicate that the wallet address is informational only and CANNOT be trusted. If the source of the DNS zone is compromised, the wallet address mapping is compromised. It is imperative that this not occur for both DNS stability, as well as wallet mapping Notationaly using DNS.

IANA Considerations This proposal does not require IANA changes.

References Normative References Informational References December 2019 2024-06-24

Example code Here is an example of how to create and retrieve a WALLET records using the domain name:

Contributors Thanks to all of the contributors for contributions to security and clarity.

yevhenii@d3.com

kai@d3.com

Acknowledgements Reviewed by:

jothan@frakes.com