diff --git a/37.md b/37.md
new file mode 100644
index 00000000..7914e90b
--- /dev/null
+++ b/37.md
@@ -0,0 +1,95 @@
+NIP-37
+======
+
+Methods for dealing with lost or compromised keys
+-------------------------------------------------
+
+`draft` `optional` `author:fiatjaf`
+
+This NIP defines a series of methods that can be used to make catastrophic key loss events less horrible.
+
+The intention here is not to claim that there is a generalized "key rotation" scheme on Nostr, but still make it
+so that in most cases people are able to move to new keys and not lost 100% of their followers and reputation
+when that happens, and also that it is possible to prevent most of the reputational damage that could be
+caused by having an evil hacker take control of someone else's keys.
+
+The implementation of this NIP could be done directly in social clients or in dedicated clients that users would
+visit from time to time in order to have an automated scan be done on their contacts and then the dedicated app
+could suggest migrating from old keys to new keys, or suggest stop following compromised keys, or even perform
+these migrations automatically.
+
+### Method A: Simple Key Deletion
+
+Based on https://github.com/nostr-protocol/nips/pull/377, the idea is that someone, after noticing that their key
+has been compromised and deciding that it is not possible to use any of the other methods here described, can
+proceed to publish the following event:
+
+```js
+{
+  "kind": 10529,
+  "pubkey": "<compromised-pubkey>",
+  "tags": [
+    ["reason", "I typed my key on anigma"]
+
+    // this is unnecessary, but it's an extra requirement to prevent people from making a 10529 event by chance
+    ["key-compromised"],
+  ],
+  "content": "",
+  // ...
+}
+```
+
+Upon receiving this, relays implementing this NIP SHOULD somehow mark it as invalid and refuse to store any more
+events from this key. Relays MAY also decide to also delete all events from this key.
+
+Upon receiving this, clients implementing this NIP SHOULD stop following the key.
+
+Clients may give users the option to "delete your public key" with this type of event. Clients SHOULD display a
+prominent message explaining that the action is not reversible, SHOULD explain that this does not guarantee their
+posts are deleted forever, and SHOULD require special confirmation such as requiring the user to type a message.
+
+### Method B: Social Key Migration
+
+The idea here is that users could pick some friends from their contact list and a threshold number to signal to
+the rest that the old key has been lost and what is the new key -- e.g. Alice can determine that, from Bob, Carol
+and Derek, if any 2 of these 3 agree, their recommendation is authoritative.
+
+This is done by publishing an event like this (for example):
+
+```js
+{
+  "kind": 10520,
+  "pubkey": "<user-pubkey-that-will-be-compromised>",
+  "tags": [
+    ["p", "<friend1-pubkey>"],
+    ["p", "<friend2-pubkey>"],
+    ["p", "<friend3-pubkey>"],
+    ["threshold", "2"]
+  ],
+  "content": "",
+  // ...
+}
+```
+
+And then, when the friends want to recommend the switch to a new pubkey, they can publish events like
+
+```js
+{
+  "kind": 1521,
+  "pubkey": "<friend1-pubkey>",
+  "tags": [
+    ["p", "<compromised-pubkey>"],
+    ["e", "<event-of-kind-10520-that-this-refers-to>"],
+    ["new-key", "<new-key>"]
+  ],
+  "content": "",
+  // ...
+}
+```
+
+Very importantly, when evaluating events of kind `1521` for a given `p`, clients should ensure that their corresponding
+event `10520` is at least 3 months older **and that an OpenTimestamps proof exists for that**.
+
+### Method C: Hierarchically Pregenerated Keys
+
+I'll write this later, just a placeholder. It's probably better to see if methods A and B work first.