nips/61.md

# NIP-61:
## 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:7337` 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.
2. Bob's client swaps the token into his wallet.

# Nutzap informational event
```jsonc
{
    "kind": 10019,
    "tags": [
        [ "relay", "wss://relay1" ],
        [ "relay", "wss://relay2" ],
        [ "mint", "https://mint1" ],
        [ "mint", "https://mint2" ],
        [ "pubkey", "<p2pk-pubkey>" ]
    ]
}
```

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

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

```jsonc
{
    kind: 7337,
    content: "[{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}]",
    pubkey: "sender-pubkey",
    tags: [
        [ "amount", "1", "sats" ],
        [ "comment", "Great point" ],
        [ "u", "https://stablenut.umint.cash", ],
        [ "e", "<zapped-event-id>", "<relay-hint>" ],
        [ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
    ]
}
```

* `.content` is an array of p2pk-locked outputs.
* `amount` is a shorthand for the combined amount of all outputs. -- Clients SHOULD validate that the sum of the amounts in the outputs matches.
* `u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
* `e` zero or one event that is being nutzapped.
* `p` exactly one pubkey, specifying the recipient of the nutzap.

# Sending a nutzap

* The sender fetches the recipient's `kind:10019`.
* The sender mints/swaps ecash on one of the recipient's listed mints.
* The sender p2pk locks to the recipient's specified pubkey in their

# Receiving nutzaps

Clients should REQ for nut zaps:
* Filtering with `#u` for mints they expect to receive ecash from.
  * this is to prevent even interacting with mints the user hasn't explicitly signaled.
* Filtering with `since` of the most recent `kind:7376` event the same user has created.
  * this can be used as a marker of the nut zaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.

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> }`.

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.

```jsonc
{
    "kind": 7376,
    "content": nip44_encrypt([
        [ "direction", "in" ], // in = received, out = sent
        [ "amount", "1", "sats" ],
        [ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
    ]),
    "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)
    ]
}
```

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

## Verifying a Cashu Zap
* Clients SHOULD check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
* Clients SHOULD check that the token is locked to the pubkey the user has listed in their `kind:10019`.

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

For this scenarios clients can:

* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.

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