EIP-1459/EIP-778 in a Browser environment


nim-waku has recently implemented EIP-1459 for peer discovery.

In short, EIP-1459 proposes a method to store and traverse a tree of peer records stored in DNS TXT entries for bootstraping purposes. Given a single enrtree url, one can retrieve connection information for a large list of nodes.
All entries are signed by a public key, which is provided as part of the enrtree url.
Link entries allows pointing to other domain name allowing discovery of further peers listed by different authorities.

EIP-1459 uses EIP-778 to encode peer information.

EIP-778 enables the encoding of arbitrary key/value peers, with the following keys having predefined meanings:

  • id
  • secp256k1
  • ip
  • tcp
  • udp
  • ip6
  • tcp6
  • udp6

In a browser environment, it is not possible to directly connect to TCP or UDP ports.
Currently, js-waku only support websocket (ws) connections. Other methods such as QUIC are being considered but not yet available.

Moreover, modern browsers only allow connections to a secure websocket (wss) within a secure context (https). For waku nodes to be reachable via wss they need to provide an SSL connection and hence setup a SSL certificate.
Modern browser accept both self-signed ip certificates and domain certificates signed by pre-defined root CA.
Also, websocket connections run over TCP as they initiate with an HTTP Upgrade.

This means that it is not possible to define peers reachable by a web app only using the keys predefined by EIP-778.


I propose to define the following keys to be used in EIP-778 entry for Waku EIP-1459 usage:

Key Value Type Value Length Value Description
fqdn utf-8 string Max 253 Bytes [1] Fully Qualified Domain Name of the node, SHOULD be used in favor of ip when the node is reachable via a FQDN.
wss Big Endian Integer - secure websocket port
wss6 Big Endian Integer - IPv6 specific secure websocket port


  • ws is not proposed as it has little practical value, https and hence wss should be preferred for all http content.
  • EIP-778 defines that The maximum encoded size of a node record is 300 bytes. . This should be kept in mind when encoding long FQDN.
  • See [1] regarding FQDN length, note that the max length is noted in characters which is not equivalent to Bytes since the introduction of utf-8 domains.
  • I could not find if any other application already use such keys (or similar) with EIP-778. I will do further investigation and update this post.


The maximum number of octets is a label is 63. RFC1035.
The maximum number of octets in a domain name is 255 octets. RFC1035
The maximum length of a fqdn, not a hostname, is 1004 characters. RFC1035
The maximum length of a full qualified hostname is 253 characters. Imputed from RFC952, RFC1123 and RFC1035.

Nimbus team reached out: Discord
Ethereum Magicians: EIP-1459/EIP-778 in a Browser environment - EIPs - Fellowship of Ethereum Magicians
Lodestar reached out, but does not seem to use any additional keys

Few ongoing discussions:

Regarding the discussions so far, it seems that it would be more future proof to simply add a single mutliaddr key that contains one or several multiaddrs for the node.

This would actually could be used by the ecosystem overall as eth2 also uses libp2p/mutladdrs.

Not sure how one would encode an array in RLP/ENR just yet.

ChainSafe does use a multiaddr entry in ENR: Discord so this is a promising direction.

ChainSafe is also using themultiaddr field. As libp2p is used in both eth2 and waku, it seems natural to slowly migrated towards the usage of multiaddr. The only remaining question is whether we could store several multiaddr in the ENR field. Indeed, AFAIK (will check), a multiaddr only contains one transport protocol stack info. ie, either TCP or UDP or WSS. you cannot express 2 in the same multaddr. Hence, ideally you’d want to store multiple multiaddr in on ENR and then select what multiaddr to dial depending on what protocol you support. Also, all multiaddr should have the same peer id. I wonder if we can deduce a peer id from secp256k1 field. If so, then the multiaddr could be peer-id-less.

Discussion taken to the spec repository:

Indeed, it now seem more appropriate to use 25/LIBP2P-DNS-DISCOVERY and direct deal with mutliaddresses for Waku v2 then extending ENR to fit multiaddr.