This EIP introduces the new
contenthash field for ENS resolvers, allowing for a better defined system of mapping names to network and content addresses. Additionally the
multihash fields are deprecated.
Multiple applications including Metamask (opens new window) and mobile clients such as Status (opens new window) have begun resolving ENS names to content hosted on distributed systems such as IPFS (opens new window) and Swarm (opens new window). Due to the various ways content can be stored and addressed, a standard is required so these applications know how to resolve names and that domain owners know how their content will be resolved.
contenthash field allows for easy specification of network and content addresses in ENS.
contenthash is introduced, which permits a wide range of protocols to be supported by ENS names. Resolvers supporting this field MUST return
true when the
supportsInterface function is called with argument
multihash are deprecated.
The value returned by
contenthash MUST be represented as a machine-readable multicodec (opens new window). The format is specified as follows:
<protoCode uvarint><value byte>
protoCodes and their meanings are specified in the multiformats/multicodec (opens new window) repository.
The encoding of the value depends on the content type specified by the protoCode. Values with protocodes of 0xe3 and 0xe4 represent IPFS and Swarm content; these values are encoded as v1 CIDs (opens new window) without a base prefix, meaning their value is formatted as follows:
When resolving a
contenthash, applications MUST use the protocol code to determine what type of address is encoded, and resolve the address appropriately for that protocol, if supported.
storage system: IPFS (0xe3) CID version: 1 (0x01) content type: dag-pb (0x70) hash function: sha2-256 (0x12) hash length: 32 bytes (0x20) hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
storage system: Swarm (0xe4) CID version: 1 (0x01) content type: swarm-manifest (0xfa) hash function: keccak256 (0x1b) hash length: 32 bytes (0x20) hash: d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
Example usage with swarm hash:
$ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 > e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
In order to support names that have an IPFS or Swarm hash in their
content field, a grace period MUST be implemented offering those name holders time to update their names. If a resolver does not support the
multihash interface, it MUST be checked whether they support the
content interface. If they do, the value of that field SHOULD be treated in a context dependent fashion and resolved. This condition MUST be enforced until at least March 31st, 2019.
contenthash, a new resolver has been developed and can be found here (opens new window), you can also find this smart contract deployed on:
- Mainnet : 0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3 (opens new window)
- Ropsten : 0xde469c7106a9fbc3fb98912bb00be983a89bddca (opens new window)
There are also implementations in multiple languages to encode and decode
Copyright and related rights waived via CC0 (opens new window).