EIP-7636: Extension of EIP-778 for "client" ENR Entry


The Ethereum network consists of nodes running various client implementations. Each client has its own set of features, optimizations, and unique behaviors. Introducing a standardized way to identify client software and its version in the ENR allows for more effective network analysis, compatibility checks, and troubleshooting. This EIP proposes the addition of a “client” field to the ENR.


Understanding the landscape of client software in the Ethereum network is crucial for developers, nodes, and network health assessment. Currently, there is no standardized method for nodes to announce their software identity and version, which can lead to compatibility issues or difficulty in diagnosing network-wide problems. Adding this to the ENR allows clients to audit network health only using discv5, and additionally track discv5 adoption across different services.


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The “client” entry is proposed to be added to the ENR following the specifications in EIP-778. This entry is OPTIONAL and can be omitted by clients that choose not to disclose such information. The key for this entry is "client".

All elements MUST be encoded as a string using the ASCII standard as described in RFC 20.

The value for this entry MUST be an RLP list:

[ClientName, Version, (BuildVersion)]
  • ClientName: A string identifier for the client software. It SHOULD be concise, free of spaces, and representative of the client application.
  • Version: A string representing the version of the client software in a human-readable format. It is RECOMMENDED to follow semantic versioning.
  • BuildVersion: An OPTIONAL string representing the build or commit version of the client software. This can be used to identify specific builds or development versions.


One key was chosen over using many keys to make efficient use of space. The use of one string, however, does not align with other EIPs of similar purpose and as such the RLP list was decided as the best encoding.

Backwards Compatibility

This EIP is fully backwards compatible as it extends the ENR specification by adding an optional entry. Existing implementations that do not recognize the “client” entry will ignore it without any adverse effects on ENR processing or network behavior.

Test Cases

A node running Geth version 1.10.0 on the mainnet might have an ENR client entry like:

["Geth", "1.10.0"]

A node running an experimental build of Nethermind might include:

["Nethermind", "1.9.53", "7fcb567"]

and an ENR of


which can be decoded to yield normal data such as seq, siqnature, id and secp256k1. Additionally, it would yield the client value of ["0x4e65746865726d696e64","0x312e392e3533","0x37666362353637"] or ["Nethermind", "1.9.53", "7fcb567"]

Security Considerations

Introducing identifiable client information could potentially be used for targeted attacks against specific versions or builds known to have vulnerabilities. It is crucial for clients implementing this EIP to consider the implications of disclosing their identity and version. Users or operators should have the ability to opt-out or anonymize this information if desired.


Copyright and related rights waived via CC0.

The disadvantage of “revealing” that kind of data is the fact that an attacker could use that info to better plan and execute certain kind of attacks. Not saying I’m against that proposal (I’m for it but maybe an even simpler approach would do it), but if I had to steelman the opposite opinion, I’d say it increases the practicality of attacking the network or individual nodes.

1 Like

I do agree that in an extreme case it could be used to exploit client specific vulnerabilities, however RLPx shows client information similar to this as part of the protocol.

This EIP should additionally make explicit in the “Security Considerations” section that this information is self reported: it is not verifiable and should not be relied upon.

Good idea, I should have specified it even though I thought people should already know that user specified data is not reliable, but with the magic Ethereum is doing now some might believe that it is reliable. I have updated it accordingly.