🤖
LNS Documentation
  • Introduction
  • Terminology
  • Frequently Asked Questions
  • Tokenomics
  • LNS Deployments
  • Registrar Frequently Asked Questions
  • Deploying LNS on a Private Chain
  • DNS Registrar guide
  • Bug Bounty Program
  • ENS Improvement Proposals
    • ENSIP-1: ENS
    • ENSIP-2: Initial Hash Registrar
    • ENSIP-3: Reverse Resolution
    • ENSIP-4: Support for contract ABIs
    • ENSIP-5: Text Records
    • ENSIP-6: DNS-in-ENS
    • ENSIP-7: Contenthash field
    • ENSIP-8: Interface Discovery
    • ENSIP-9: Multichain Address Resolution
    • ENSIP-10: Wildcard Resolution
    • ENSIP-11: EVM compatible Chain Address Resolution
    • ENSIP-12: Avatar Text Records
  • Dapp Developer Guide
    • LNS Enabling your DApp
    • LNS Libraries
    • Working with LNS
    • Resolving Names
    • Managing Names
    • Registering & Renewing Names
    • LNS Front-End Design Guidelines
    • LNS as NFT
  • Contract API Reference
    • Name Processing
    • Registry
    • ReverseRegistrar
    • PublicResolver
    • .bch Permanent Registrar
      • Registrar
      • Controller
    • DNS Registrar
  • Contract Developer Guide
    • Resolving Names On-chain
    • Writing a Resolver
    • Writing a Registrar
    • LNS Support Chat
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Specification
  • Copyright
Edit on GitHub
  1. ENS Improvement Proposals

ENSIP-7: Contenthash field

Introduces a field for storing content addresses and hashes in ENS (formerly EIP-1577).

PreviousENSIP-6: DNS-in-ENSNextENSIP-8: Interface Discovery

Last updated 3 years ago

Author

Status

Final

Created

2018-11-13

Abstract

This ENSIP introduces the new contenthash field for ENS resolvers, allowing for a better defined system of mapping names to network and content addresses. Additionally the content and multihash fields are deprecated.

Motivation

Multiple applications including and mobile clients such as have begun resolving ENS names to content hosted on distributed systems such as and . 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.

The contenthash field allows for easy specification of network and content addresses in ENS.

Specification

The field 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 0xbc1c58d1.

The fields content and multihash are deprecated.

The value returned by contenthash MUST be represented as a machine-readable . The format is specified as follows:

<protoCode uvarint><value []byte>

protoCodes and their meanings are specified in the 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 without a base prefix, meaning their value is formatted as follows:

<protoCode uvarint><cid-version><multicodec-content-type><multihash-content-address>

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.

Example

IPFS

Input data:

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

Binary format:

0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f

Text format:

ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4

Swarm

Input data:

storage system: Swarm (0xe4)
CID version: 1 (0x01)
content type: swarm-manifest (0xfa)
hash function: keccak256 (0x1b)
hash length: 32 bytes (0x20)
hash: d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162

Binary format:

0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162

Text format:

bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162

Example usage with swarm hash:

$ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162                                 
> e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162

Fallback

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.

Implementation

There are also implementations in multiple languages to encode and decode contenthash:

Copyright

Dean Eigenmann <>, Nick Johnson <>

To support contenthash, a new resolver has been developed and can be found , you can also find this smart contract deployed on:

Mainnet :

Ropsten :

Copyright and related rights waived via .

Metamask
Status
IPFS
Swarm
multicodec
multiformats/multicodec
CIDs
here
0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3
0xde469c7106a9fbc3fb98912bb00be983a89bddca
JavaScript
Python
CC0
dean@ens.domains
nick@ens.domains