diff --git a/standards/core/enr.md b/standards/core/enr.md
index adab1e3..9ab4122 100644
--- a/standards/core/enr.md
+++ b/standards/core/enr.md
@@ -8,26 +8,27 @@ contributors:
 
 ## Abstract
 
-This RFC describes the usage of the ENR (Ethereum Node Records) format for [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) purposes.
+This specification describes the usage of the ENR (Ethereum Node Records)
+format for [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) purposes.
 The ENR format is defined in [EIP-778](https://eips.ethereum.org/EIPS/eip-778) [[3]](#references).
 
-This RFC is an extension of EIP-778, ENR used in Waku v2 MUST adhere to both EIP-778 and 31/WAKU2-ENR.
+This specification is an extension of EIP-778, ENR used in Waku MUST adhere to both EIP-778 and 31/WAKU2-ENR.
 
 ## Motivation
 
-EIP-1459 with the usage of ENR has been implemented [[1]](#references) [[2]](#references) as a discovery protocol for Waku v2.
+EIP-1459 with the usage of ENR has been implemented [[1]](#references) [[2]](#references) as a discovery protocol for Waku.
 
 EIP-778 specifies a number of pre-defined keys.
 However, the usage of these keys alone does not allow for certain transport capabilities to be encoded,
 such as Websocket.
-Currently, Waku v2 nodes running in a Browser only support websocket transport protocol.
+Currently, Waku nodes running in a browser only support websocket transport protocol.
 Hence, new ENR keys need to be defined to allow for the encoding of transport protocol other than raw TCP.
 
 ### Usage of Multiaddr Format Rationale
 
 One solution would be to define new keys such as `ws` to encode the websocket port of a node.
 However, we expect new transport protocols to be added overtime such as quic.
-Hence, this would only provide a short term solution until another RFC would need to be added.
+Hence, this would only provide a short term solution until another specification would need to be added.
 
 Moreover, secure websocket involves SSL certificates.
 SSL certificates are only valid for a given domain and ip, so an ENR containing the following information:
@@ -47,10 +48,12 @@ Hence, it uses [multiaddr](https://github.com/multiformats/multiaddr) to format
 Directly storing one or several multiaddresses in the ENR would fix the issues listed above:
 
 - multiaddr is self-describing and support addresses for any network protocol:
-  No new RFC would be needed to support encoding other transport protocols in an ENR.
+  No new specification would be needed to support encoding other transport protocols in an ENR.
 - multiaddr contains both the host and port information, allowing the ambiguity previously described to be resolved.
 
-## `multiaddrs` ENR key
+## Wire Format
+
+### `multiaddrs` ENR key
 
 We define a `multiaddrs` key.
 
@@ -122,9 +125,9 @@ then it is not needed to use the `multiaddrs` key.
 
 Supported key type is `secp256k1` only.
 
-In the future, an extension of this RFC could be made to support other elliptic curve cryptography such as `ed25519`.
+In the future, an extension of this specification could be made to support other elliptic curve cryptography such as `ed25519`.
 
-## `waku2` ENR key
+### `waku2` ENR key
 
 We define a `waku2` field key:
 
@@ -141,17 +144,17 @@ We define a `waku2` field key:
   If a protocol is not supported, the corresponding field MUST be set to `false`.
   Indicating positive support for any specific protocol is OPTIONAL,
   though it MAY be required by the relevant application or discovery process.
-- Flags marked as `undef` is not yet defined.
+- Flags marked as `undef` is not yet defined.****
   These SHOULD be set to `false` by default.
 
 ### Usage
 
-- A Waku v2 node MAY choose to populate the `waku2` field for enhanced discovery capabilities,
+- A Waku node MAY choose to populate the `waku2` field for enhanced discovery capabilities,
   such as indicating supported protocols.
   Such a node MAY indicate support for any specific protocol by setting the corresponding flag to `true`.
-- Waku v2 nodes that want to participate in [Node Discovery Protocol v5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) [[4]](#references), however,
+- Waku nodes that want to participate in [Node Discovery Protocol v5](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/33/discv5.md) [[4]](#references), however,
   MUST implement the `waku2` key with at least one flag set to `true`.
-- Waku v2 nodes that discovered other participants using Discovery v5,
+- Waku nodes that discovered other participants using Discovery v5,
   MUST filter out participant records that do not implement this field or do not have at least one flag set to `true`.
 - In addition, such nodes MAY choose to filter participants on specific flags (such as supported protocols),
   or further interpret the `waku2` field as required by the application.