1 files changed, 10 insertions, 8 deletions

diff --git a/61.md b/61.md
index 2cf27d5..4b4020a 100644
--- a/61.md
+++ b/61.md
@@ -22,8 +22,8 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
     "tags": [
         [ "relay", "wss://relay1" ],
         [ "relay", "wss://relay2" ],
-        [ "mint", "https://mint1" ],
-        [ "mint", "https://mint2" ],
+        [ "mint", "https://mint1", "usd", "sat" ],
+        [ "mint", "https://mint2", "sat" ],
         [ "pubkey", "<p2pk-pubkey>" ]
     ]
 }
@@ -32,13 +32,13 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
 `kind:10019` is an event that is useful for others to know how to send money to the user.
 
 * `relay` - Relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
-* `mint` - Mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money.
-* `pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient.
+* `mint` - Mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
+* `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.
 
-Clients MUST prefix the recipient pubkey with `"02"` (for nostr<>cashu pubkey compatibility).
+Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
 
 ```jsonc
 {
@@ -46,7 +46,7 @@ Clients MUST prefix the recipient pubkey with `"02"` (for nostr<>cashu pubkey co
     content: "[{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}]",
     pubkey: "sender-pubkey",
     tags: [
-        [ "amount", "1", "sats" ],
+        [ "amount", "1", "sat" ],
         [ "comment", "Great point" ],
         [ "u", "https://stablenut.umint.cash", ],
         [ "e", "<zapped-event-id>", "<relay-hint>" ],
@@ -61,6 +61,8 @@ Clients MUST prefix the recipient pubkey with `"02"` (for nostr<>cashu pubkey co
 * `e` zero or one event that is being nutzapped.
 * `p` exactly one pubkey, specifying the recipient of the nutzap.
 
+WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible to verify nutzaps without talking to the mint.
+
 # Sending a nutzap
 
 * The sender fetches the recipient's `kind:10019`.
@@ -91,7 +93,7 @@ Multiple `kind:7337` events can be tagged in the same `kind:7376` event.
     "kind": 7376,
     "content": nip44_encrypt([
         [ "direction", "in" ], // in = received, out = sent
-        [ "amount", "1", "sats" ],
+        [ "amount", "1", "sat" ],
         [ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
     ]),
     "tags": [
@@ -117,7 +119,7 @@ Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relay
 3. A nut zap MUST be sent to a mint the recipient has listed in their `kind:10019` event or to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.
 
 ## Appendix 1: Alternative P2PK pubkey
-Sometimes clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
+Clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
 
 For this scenarios clients can: