diff --git a/22.md b/22.md
index 68891c4a..550aae4e 100644
--- a/22.md
+++ b/22.md
@@ -6,7 +6,7 @@ Key Migration
 
 `draft` `optional`
 
-Kind 18 informs the network that the owner of the pubkey is migrating to a new key. 
+`Kind:18` informs the network that the owner of the pubkey is migrating to a new key. 
 
 The event MUST contain a single `p` tag with the new pubkey owner will be using. 
 
@@ -23,21 +23,21 @@ The event MUST contain a single `p` tag with the new pubkey owner will be using.
 
 ## Confirmation Chains
 
-Since the owner's keys might have leaked, `Kind:18`s **alone** can't be trusted. 
+Since the owner's keys might have leaked and this event might come from an attacker, `Kind:18`s **alone** can't be trusted. 
 
 Close acquaintances to the owner should verify the owner's intention off nostr and signal their conclusion by adding the new key to their contact lists. 
 
-Others can follow based on their individual trust on such those acquaintances.
+Others may choose to follow suit based on their trust in such acquaintances.
 
 ## Interpretation
 
-The presence of one or more `kind:18`s, no matter who writes it, declares the key to be out of use, unreliable, unsafe and potentially stolen: No event, past and future, from this key can be trusted anymore.  
+The presence of one or more `kind:18`s, no matter who writes it, declares the key to be out of use, unreliable, unsafe, and potentially stolen: No event, past and future, from this key can be trusted anymore.  
 
 Users that have a `kind:18` published by their keys MUST migrate to a new key. 
 
 There can be multiple `kind:18`s pointing to separate new keys. Finding which event is the right one requires observing contact lists of trusted keys.
 
-## Information retention
+## Information Retention
 
 Clients SHOULD send `kind:18` to as many relays as possible, not only to the owner's relay list.  
 
@@ -55,7 +55,7 @@ Clients SHOULD offer ways to investigate and verify if:
 1. the transition to a new key was intended by the owner OR 
 2. if this is an attack and the new key is controlled by an attacker.
 
-Clients MAY download follow lists of the user's contact lists and display when a follow has switched to a new key. 
+Clients MAY download follow lists of the user's contact lists and display them when a follow has switched to a new key. 
 
 It's ok to delay verification until trusted keys start informing their assessments.