Zapping in Plaza is Lightning and only the receipt half. Kind 9735 is in engagement_kinds, and zapClaim establishes who actually paid from the embedded kind:9734 request rather than trusting the receipt's own pubkey, which belongs to a payment server. There is no kind 10019 and no kind 9321 anywhere in the app.
A nutzap is a different thing from a zap receipt, and the difference is the point: the event carries the money. A kind:9321 holds ecash proofs locked to the recipient's P2PK public key, published to the relays their kind:10019 nominates, drawn from a mint their kind:10019 says they accept. No invoice, no LNURL callback, nothing in the middle that has to still be running, because the receipt is the payment.
Three parts.
Being payable. Publish my own kind:10019: the mints I accept a proof from, the relays to send it to, and the P2PK pubkey proofs lock to, which is the wallet key and not my identity key. Nothing writes it today, and without it I cannot be nutzapped at all.
Sending. Mint or swap a proof at a mint the recipient listed, lock it to their P2PK key, publish kind:9321 to their kind:10019 relays with the note it is about tagged. A recipient who lists no mint I hold gets said plainly, not a button that fails.
Receiving. Watch those relays for kind 9321 addressed to me, redeem the proofs into my wallet, and record it as kind:7376 so the same nutzap can never be redeemed or counted twice. Proofs locked to a key I do not hold are somebody else's and get ignored rather than shown as income.
This needs the wallet to exist first: a nutzap with nowhere to redeem into is a proof sitting inside an event.
Done
My profile can receive a nutzap without me running anything. One sent to me is redeemed, shows in my balance, and a re-read of the relay does not double it. One I send arrives in another client that speaks NIP-61.
Zapping in Plaza is Lightning and only the receipt half. Kind 9735 is in
engagement_kinds, andzapClaimestablishes who actually paid from the embedded kind:9734 request rather than trusting the receipt's own pubkey, which belongs to a payment server. There is no kind 10019 and no kind 9321 anywhere in the app.A nutzap is a different thing from a zap receipt, and the difference is the point: the event carries the money. A kind:9321 holds ecash proofs locked to the recipient's P2PK public key, published to the relays their kind:10019 nominates, drawn from a mint their kind:10019 says they accept. No invoice, no LNURL callback, nothing in the middle that has to still be running, because the receipt is the payment.
Three parts.
Being payable. Publish my own kind:10019: the mints I accept a proof from, the relays to send it to, and the P2PK pubkey proofs lock to, which is the wallet key and not my identity key. Nothing writes it today, and without it I cannot be nutzapped at all.
Sending. Mint or swap a proof at a mint the recipient listed, lock it to their P2PK key, publish kind:9321 to their kind:10019 relays with the note it is about tagged. A recipient who lists no mint I hold gets said plainly, not a button that fails.
Receiving. Watch those relays for kind 9321 addressed to me, redeem the proofs into my wallet, and record it as kind:7376 so the same nutzap can never be redeemed or counted twice. Proofs locked to a key I do not hold are somebody else's and get ignored rather than shown as income.
This needs the wallet to exist first: a nutzap with nowhere to redeem into is a proof sitting inside an event.
Done
My profile can receive a nutzap without me running anything. One sent to me is redeemed, shows in my balance, and a re-read of the relay does not double it. One I send arrives in another client that speaks NIP-61.