From 5b39572abf0acf71b2f8d175fc21a30f7440ca4d Mon Sep 17 00:00:00 2001
From: Dean Eigenmann <dean@tokenate.io>
Date: Tue, 13 Nov 2018 05:09:15 +0100
Subject: [PATCH] Multiaddr support for ENS (#1577)

* Create eip-1577.md

* Update eip-1577.md

* Update eip-1577.md
---
 EIPS/eip-1577.md | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 EIPS/eip-1577.md

diff --git a/EIPS/eip-1577.md b/EIPS/eip-1577.md
new file mode 100644
index 00000000..15d14f35
--- /dev/null
+++ b/EIPS/eip-1577.md
@@ -0,0 +1,59 @@
+---
+eip: 1577
+title: Multiaddr support for ENS
+author: Dean Eigenmann <dean@ens.domains>, Nick Johnson <nick@ens.domains>
+type: Standards Track
+category: ERC
+status: Draft
+created: 2018-11-13
+discussion-to: https://github.com/ethereum/EIPs/pull/1577
+---
+
+## Abstract
+
+This EIP introduces the new `multiaddr` 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 [Metamask](https://metamask.io/) and mobile wallets such as [Status](https://status.im) have begun resolving ENS names to content hosted on distributed systems such as [IPFS](https://ipfs.io/) and [Swarm](https://swarm-guide.readthedocs.io). 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 `multiaddr` field allows for easy specification of network and content addresses in ENS.
+
+## Specification
+
+The field `multiaddr` 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 `0x4cb7724c`.
+
+The fields `content` and `multihash` are deprecated.
+
+Addresses MUST be represented as a machine-readable [multiaddr](https://github.com/multiformats/multiaddr). The format is specified as follows:
+
+```
+<protoCode uvarint><value []byte>
+```
+
+When resolving a multiaddr, 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
+
+Text format:
+
+```
+/p2p/QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4
+```
+
+Binary format:
+
+```
+a50322122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
+```
+
+### 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 `multiaddr` 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 December 31st, 2018.
+
+### Implementation
+
+To support `multiaddr`, a new resolver has been developed and can be found [here](https://github.com/ensdomains/resolvers/blob/master/contracts/PublicResolver.sol).
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).