NIPs nostr improvement proposals

NIP-61: - Nut Zaps

Table of Contents

Nut Zaps

A Nut Zap is a P2PK cashu token where the payment itself is the receipt.

High-level flow

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: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:9321 events p-tagging him from his relays.
  2. Bob's client swaps the token into his wallet.

Nutzap informational event

{
"kind": 10019,
"tags": [
[ "relay", "wss://relay1" ],
[ "relay", "wss://relay2" ],
[ "mint", "https://mint1", "usd", "sat" ],
[ "mint", "https://mint2", "sat" ],
[ "pubkey", "<p2pk-pubkey>" ]
]
}

kind:10019 is an event that is useful for others to know how to send money to the user.

Nutzap event

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).

{
kind: 9321,
content: "Thanks for this great idea.",
pubkey: "sender-pubkey",
tags: [
[ "amount", "1" ],
[ "unit", "sat" ],
[ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
[ "u", "https://stablenut.umint.cash", ],
[ "e", "<zapped-event-id>", "<relay-hint>" ],
[ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
]
}

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

Receiving nutzaps

Clients should REQ for nut zaps:

Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.

{ "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:9321 events can be tagged in the same kind:7376 event.

{
"kind": 7376,
"content": nip44_encrypt([
[ "direction", "in" ], // in = received, out = sent
[ "amount", "1", "sat" ],
[ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
]),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
[ "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)
]
}

Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relays.

Verifying a Cashu Zap

Final Considerations

  1. Clients SHOULD guide their users to use NUT-11 (P2PK) compatible-mints in their kind:10019 event to avoid receiving nut zaps anyone can spend

  2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.

  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

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:

This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.