diff --git a/47.md b/47.md
index 515690fc..5d78995d 100644
--- a/47.md
+++ b/47.md
@@ -53,7 +53,7 @@ It should also contain supported encryption modes as described in the [Encryptio
 {
     "kind": 13194,
     "tags": [
-        ["encryption", "nip44 nip04"], // List of supported encryption schemes as described in the Encryption section.
+        ["encryption", "nip44_v2 nip04"], // List of supported encryption schemes as described in the Encryption section.
         ["notifications", "payment_received payment_sent"]
         // ...
     ],
@@ -78,11 +78,11 @@ Example request:
 {
     "kind" 23194,
     "tags": [
-        ["encryption", "nip44"],
+        ["encryption", "nip44_v2"],
         ["p", "03..." ] // public key of the wallet service.
         // ...
     ],
-    "content": nip44_encrypt({
+    "content": nip44_encrypt({ // Encryption type corresponds to the `encryption` tag.
         "method": "pay_invoice", // method, string
         "params": { // params, object
             "invoice": "lnbc50n1..." // command-related data
@@ -97,7 +97,7 @@ Example response:
 {
     "kind" 23195,
     "tags": [
-        ["encryption", "nip44"],
+        ["encryption", "nip44_v2"],
         ["p", "03..." ] // public key of the requesting client app
         ["e", "1234"] // id of the request event this is responding to
         // ...
@@ -543,11 +543,11 @@ Notification:
 ## Encryption
 
 The initial version of NWC used [NIP-04](04.md) for encryption which has been deprecated and replaced by [NIP-44](44.md). NIP-44 should always be preferred for encryption, but there may be legacy cases
-where wither the **wallet service** or **client** has not yet migrated to NIP-44. The **wallet service** and **client** should negotiate the encryption method to use based on the `encryption` tags in the `info` event.
+where the **wallet service** or **client** has not yet migrated to NIP-44. The **wallet service** and **client** should negotiate the encryption method to use based on the `encryption` tag in the `info` event.
 
 The negotiation works as follows.
 
-1. The **wallet service** includes an `encryption` tag in the `info` event. This tag contains a space-separated list of encryption schemes that the **wallet service** supports (eg. `nip44 nip04`)
+1. The **wallet service** includes an `encryption` tag in the `info` event. This tag contains a space-separated list of encryption schemes that the **wallet service** supports (eg. `nip44_v2 nip04`)
 2. The **client application** includes an `encryption` tag in each request event. This tag contains the encryption scheme which should be used for the request. The **client application** should always prefer nip44 if supported by the **wallet service**.
 
 ### Info event
@@ -559,7 +559,7 @@ if a wallet service supports nip44, but also allows backwards-compatibility to n
 {
     "kind": 13194,
     "tags": [
-        ["encryption", "nip44 nip04"],
+        ["encryption", "nip44_v2 nip04"],
         // ...
     ],
     "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions get_info",
@@ -582,7 +582,7 @@ For example, if the client application supports nip44, the request event might l
 {
     "kind": 23194,
     "tags": [
-        ["encryption", "nip44"],
+        ["encryption", "nip44_v2"],
         // ...
     ],
     // ...
@@ -611,7 +611,7 @@ This NIP does not specify any requirements on the type of relays used. However,
   "created_at": 1713883677,
   "kind": 13194,
   "tags": [
-    [ "encryption", "nip44 nip04" ],
+    [ "encryption", "nip44_v2 nip04" ],
     [
       "notifications",
       "payment_received payment_sent"