diff --git a/22.md b/22.md
new file mode 100644
index 0000000000..688b63ebe4
--- /dev/null
+++ b/22.md
@@ -0,0 +1,59 @@
+NIP-22
+======
+
+Key Revocation
+--------------
+
+`draft` `optional`
+
+`Kind:18` informs the network that the owner of the current public key is revoking it.
+
+The event MUST include a single `p` tag containing the new public key the owner intends to use.
+
+```js
+{
+  "kind": 18,   
+  "tags": [
+    ["p", "<pubkey>", "<relay_url>"],
+  ],
+  "content": ""
+  //...
+}
+```
+
+## Interpretation
+
+The presence of one or more `kind:18` events indicates that the key no longer represents the original owner. The key MUST be considered unreliable, unsafe, and potentially compromised. Consequently, no past or future events from this key, including `kind:18` events themselves, can be trusted.
+
+`kind:18` events may be created by the original owner or by an attacker who has taken control of the account and is attempting to redirect followers to a new key that the attacker controls. Because of that, close acquaintances of the owner should verify the owner's new key outside of Nostr. The new key may or may not match the `p` tag in the `kind:18` event.
+
+Users whose keys have had a `kind:18` event published MUST migrate to a new key.
+
+## Confirmation Chains
+
+There may be multiple `kind:18` events pointing to different new keys. Determining the correct key requires manual verification through trusted acquaintances of the account holder.
+
+Trusted acquaintances SHOULD update their contact lists with the new key and inform their followers by reposting the key revocation.
+
+Others may choose to follow based on their trust in these acquaintances. The network SHOULD slowly update its records based on an unrolling web of trust
+
+## Information Retention
+
+Clients SHOULD broadcast `kind:18` events to as many relays as possible, not just those in the owner's relay list.
+
+Relays and Clients MUST reject Event Deletion requests for kind:18 events ([NIP-09](09.md)).
+
+Clients SHOULD use Generic Reposts (`kind:16`) to warn followers and improve the retention of `kind:18` events on relays. These Generic Reposts MUST include a JSON-stringified version of the `kind:18` in the `.content` field and a `k` tag set to 18.
+
+Generic Repost events MUST NOT be considered the user's final decision on which key to switch to.
+
+## Client Behavior
+
+Upon receiving a new `kind:18` event, Clients MUST warn their users that the associated pubkey is unsafe.
+
+Clients MAY use follow lists of their user's follows to display whether anyone they trust has switched to the new key.
+
+Upon confirmation of the new key, Clients SHOULD offer a transition by:
+1. Updating the contact list accordingly
+2. Adjusting any NIP-51 lists accordingly
+3. Adding the old key to the Mute List (Optional)