diff --git a/61.md b/61.md
index 4b4020a..4e2148c 100644
--- a/61.md
+++ b/61.md
@@ -9,10 +9,10 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
 ## Alice nutzaps Bob
 1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
 2. She mints a token at that mint (or swaps some tokens she already had in that mint) p2pk-locked to the pubkey Bob has listed in his `kind:10019`.
-3. She publishes a `kind:7337` event to the relays Bob indicated with the proofs she minted.
+3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
 
 ## Bob receives the nutzap
-1. At some point, Bob's client fetches `kind:7337` events p-tagging him from his relays.
+1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
 2. Bob's client swaps the token into his wallet.
 
 # Nutzap informational event
@@ -36,13 +36,13 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
 * `pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient. This is explained in Appendix 1.
 
 ## Nutzap event
-Event `kind:7337` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
+Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
 
 Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
 
 ```jsonc
 {
-    kind: 7337,
+    kind: 9321,
     content: "[{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}]",
     pubkey: "sender-pubkey",
     tags: [
@@ -79,14 +79,14 @@ Clients should REQ for nut zaps:
 
 Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
 
-`{ "kinds": [7337], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
+`{ "kinds": [9321], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
 
 Upon receiving a new nut zap, the client should swap the tokens into a wallet the user controls, either a [[NIP-60]] wallet, their own LN wallet or anything else.
 
 ## Updating nutzap-redemption history
 When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nut zap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
 
-Multiple `kind:7337` events can be tagged in the same `kind:7376` event.
+Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
 
 ```jsonc
 {
@@ -98,8 +98,8 @@ Multiple `kind:7337` events can be tagged in the same `kind:7376` event.
     ]),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
-        [ "e", "<7337-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
-        [ "p", "sender-pubkey" ] // pubkey of the author of the 7337 event (nutzap sender)
+        [ "e", "<9321-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
+        [ "p", "sender-pubkey" ] // pubkey of the author of the 9321 event (nutzap sender)
     ]
 }
 ```