EIPs/EIPS/eip-2304.md

eip	title	author	type	category	status	created	discussions-to	requires
2304	Multichain address resolution for ENS	Nick Johnson <nick@ens.domains>	Standards Track	ERC	Draft	2019-09-09	https://discuss.ens.domains/t/new-standard-proposal-ens-multicoin-support/1148	137

Abstract

This EIP introduces new overloads for the the addr field for ENS resolvers, which permit resolution of addresses for other blockchains via ENS.

Motivation

With the increasing uptake of ENS by multi-coin wallets, wallet authors have requested the ability to resolve addresses for non-Ethereum chains inside ENS. This specification standardises a way to enter and retrieve these addresses in a cross-client fashion.

Specification

A new accessor function for resolvers is specified:

function addr(bytes32 node, uint coinType) external view returns(bytes memory);

The EIP165 interface ID for this function is 0xf1cb7e06.

When called on a resolver, this function must return the cryptocurrency address for the specified namehash and coin type. A zero-length string must be returned if the specified coin ID does not exist on the specified node.

coinType is the cryptocurrency coin type index from SLIP44.

The return value is the cryptocurency address in its native binary format. Detailed descriptions of the binary encodings for several popular chains are provided in the Address Encoding section below.

A new event for resolvers is defined:

event AddressChanged(bytes32 indexed node, uint coinType, bytes newAddress);

Resolvers MUST emit this event on each change to the address for a name and coin type.

Recommended accessor functions

The following function provides the recommended interface for changing the addresses stored for a node. Resolvers SHOULD implement this interface for setting addresses unless their needs dictate a different interface.

function setAddr(bytes32 node, uint coinType, bytes calldata addr);

setAddr adds or replaces the address for the given node and coin type. The parameters for this function are as per those described in addr() above.

This function emits an AddressChanged event with the new address; see also the backwards compatibility section below for resolvers that also support addr(bytes32).

Address Encoding

In general, the native binary representation of the address should be used, without any checksum commonly used in the text representation.

A table of encodings for common blockchains is provided, followed by a more detailed description of each format. In the table, 'Format' describes the encoding used to represent the bytes in text format, 'Decoded' describes the result of decoding this format, and 'On ENS' describes how this should be stored in ENS as bytes.

Cryptocurrency	Format	Decoded	On ENS
Ethereum	hex-checksum	<20 byte hash>	<20 byte hash>
Bitcoin	base58check	0x00 <20 byte hash>	0x76a914 <20 byte hash> 0x88ac
Bitcoin	base58check	0x05 <20 byte hash>	0xa914 <20 byte hash> 0x87
Bitcoin	bech32	<witness version> <witness program>	<OP_n> <PUSH_m> <witness program>

Ethereum

To translate a text format Ethereum address into binary format, simply remove the '0x' prefix and hex decode it. 0x314159265dD8dbb310642f98f50C066173C1259b is hex-decoded and stored as the 20 bytes 314159265dd8dbb310642f98f50c066173c1259b.

Before decoding, the EIP 55 address checksum must be checked. Addresses with invalid checksums that are not all uppercase or all lowercase MUST be rejected with an error. Implementations may choose whether to accept non-checksummed addresses, but the authors recommend at least providing a warning to users in this situation.

When encoding an address from binary to text, an EIP 55 checksum MUST be used - so the correct encoding of the above address is 0x314159265dD8dbb310642f98f50C066173C1259b.

Bitcoin

Bitcoin addresses are encoded as the scriptPubkey for the address. Common Bitcoin addressing formats are encoded and decoded as follows:

P2PKH and P2SH

Pay to Public Key Hash and Pay To Script Hash addresses are base58check encoded. After decoding, the first byte is a version byte. For example, the Bitcoin address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa base58check decodes to the 21 bytes 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18.

P2PKH addresses have a version byte of 0, followed by a 20 byte pubkey hash. Their scriptPubkey encoding (specified here) is OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG.

The above example address is thus encoded as the 25 bytes 76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac.

P2SH addresses have a version byte of 5, followed by a 20 byte script hash. Their scriptPubkey encoding (specified here) is OP_HASH160 <scriptHash> OP_EQUAL. A Bitcoin address of 3Ai1JZ8pdJb2ksieUV8FsxSNVJCpoPi8W6 decodes to the 21 bytes 0562e907b15cbf27d5425399ebf6f0fb50ebb88f18 and is encoded as the 23 bytes a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1887.

SegWit addresses

SegWit addresses are encoded with bech32. Bech32 addresses consist of a human-readable part - 'bc' for Bitcoin mainnet - and a machine readable part. This decodes to a 'witness version', between 0 and 15, and a 'witness program', as defined in BIP141.

The scriptPubkey encoding for a bech32 address, as defined in BIP141, is OP_n, where n is the witness version, followed by a push of the witness program. Note this warning from BIP173:

Implementations should take special care when converting the address to a scriptPubkey, where witness version n is stored as OP_n. OP_0 is encoded as 0x00, but OP_1 through OP_16 are encoded as 0x51 though 0x60 (81 to 96 in decimal). If a bech32 address is converted to an incorrect scriptPubKey the result will likely be either unspendable or insecure.

For example, the SegWit address BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4 decodes to a version of 0 and a witness script of 751e76e8199196d454941c45d1b3a323f1433bd6, and then encodes to a scriptPubkey of 0014751e76e8199196d454941c45d1b3a323f1433bd6.

Example

An example implementation of a resolver that supports this EIP is provided here:

pragma solidity ^0.5.8;

contract AddrResolver is ResolverBase {
    bytes4 constant private ADDR_INTERFACE_ID = 0x3b3b57de;
    bytes4 constant private ADDRESS_INTERFACE_ID = 0xf1cb7e06;
    uint constant private COIN_TYPE_ETH = 60;

    event AddrChanged(bytes32 indexed node, address a);
    event AddressChanged(bytes32 indexed node, uint coinType, bytes newAddress);

    mapping(bytes32=>mapping(uint=>bytes)) _addresses;

    /**
     * Sets the address associated with an ENS node.
     * May only be called by the owner of that node in the ENS registry.
     * @param node The node to update.
     * @param a The address to set.
     */
    function setAddr(bytes32 node, address a) external authorised(node) {
        setAddr(node, COIN_TYPE_ETH, addressToBytes(a));
    }

    /**
     * Returns the address associated with an ENS node.
     * @param node The ENS node to query.
     * @return The associated address.
     */
    function addr(bytes32 node) public view returns (address) {
        bytes memory a = addr(node, COIN_TYPE_ETH);
        if(a.length == 0) {
            return address(0);
        }
        return bytesToAddress(a);
    }

    function setAddr(bytes32 node, uint coinType, bytes memory a) public authorised(node) {
        emit AddressChanged(node, coinType, a);
        if(coinType == COIN_TYPE_ETH) {
            emit AddrChanged(node, bytesToAddress(a));
        }
        _addresses[node][coinType] = a;
    }

    function addr(bytes32 node, uint coinType) public view returns(bytes memory) {
        return _addresses[node][coinType];
    }

    function supportsInterface(bytes4 interfaceID) public pure returns(bool) {
        return interfaceID == ADDR_INTERFACE_ID || interfaceID == ADDRESS_INTERFACE_ID || super.supportsInterface(interfaceID);
    }
}

Implementation

An implementation of this interface is provided in the ensdomains/resolvers repository.

Backwards Compatibility

If the resolver supports the addr(bytes32) interface defined in EIP137, the resolver MUST treat this as a special case of this new specification in the following ways:

1. The value returned by addr(node) from EIP137 should always match the value returned by addr(node, 60) (60 is the coin type ID for Ethereum).
2. Anything that causes the AddrChanged event from EIP137 to be emitted must also emit an AddressChanged event from this EIP, with the coinType specified as 60, and vice-versa.

Tests

The table below specifies test vectors for valid address encodings for each cryptocurrency described above.

Cryptocurrency	Text	Onchain (hex)
Ethereum	0x314159265dD8dbb310642f98f50C066173C1259b	314159265dd8dbb310642f98f50c066173c1259b
Bitcoin	1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa	76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac
Bitcoin	3Ai1JZ8pdJb2ksieUV8FsxSNVJCpoPi8W6	a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1887
Bitcoin	BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4	0014751e76e8199196d454941c45d1b3a323f1433bd6

Copyright

Copyright and related rights waived via CC0.