NIP-61: Nutzaps
A zap can be ecash instead of an invoice receipt
Lightning zaps use an invoice and a receipt. Nutzaps use Cashu ecash: the sender gives the recipient a token locked to a key the recipient controls. The payment is not merely accompanied by a receipt; the payment object is the receipt.
That makes NIP-61 interesting for social money. A user can publish a small Cashu payment event to a recipient's chosen relays, tied to a note or profile, without going through the exact same LNURL receipt path as NIP-57.
It also makes the risk sharper. If the sender uses a mint the recipient did not list, funds can be burned or ignored. If wallet state is mishandled, the proof can be lost or double-spent. Ecash is simple to send and unforgiving to implement casually.
Recipient info, P2PK locks and kind 9321 payments
The recipient publishes kind 10019, listing relays where they read nutzap events, mints they accept and the P2PK public key that must be used for receiving. The source explicitly says implementations must not use the target user's main Nostr public key for this P2PK lock.
The sender publishes kind 9321, p-tagging the recipient and including one or more Cashu proof tags, unit, mint URL and optional references to the event being nutzapped. The mint URL must match exactly one listed by the recipient.
Receiving clients query for kind 9321 events p-tagging the user and needs to filter by accepted mint URLs. Then the wallet swaps the token into its own wallet state, which brings NIP-60 back into the flow.
Nutzaps evolved alongside the Cashu wallet NIP
Pablo Fernandez introduced the visible Cashu wallet and Nutzaps work in October 2024. Early 2025 changes removed an a tag, refined JSON examples, simplified NIP-60/61 together and adjusted nitpicks around event shape.
In August 2025, a missing k tag was added in related reaction-style contexts. In October 2025, Rob Woodgate added the base unit tag to kind 9321. The details are small, but units matter when the value can be sat, usd, eur or another mint-supported unit.
The history shows a payment standard being forced to answer wallet-accounting questions rather than only social UX questions.
Nutzaps depend on explicit mint trust
A sender must fetch kind 10019, select one of the recipient's listed mints, mint or swap proofs there, P2PK-lock them to the recipient's listed wallet key and publish the nutzap to the listed relays. Skipping the receiver-info event is not a shortcut; it is how money gets sent somewhere the recipient cannot or will not redeem.
Nutsack and the wider Cashu ecosystem are the clearest implementation references today. NIP-60/61 support appears in Cashu wallet inventories, and the Sovereign Engineering project list has described Alphaama work around NIP-60 and NIP-61 Cashu flows.
The best UI does not need to ask you to understand every proof tag, but it needs to show mint, unit, amount, recipient, target note and redemption state. A nutzap that has not been swapped yet is not the same thing as settled wallet balance.
A beautiful social payment can still burn money
Nutzaps are elegant because the payment object is the social object. They are risky for the same reason. A bad mint, wrong P2PK key, unsupported unit or stale recipient info can turn a tip into a loss.
Clients need to make redemption state visible and avoid treating every kind 9321 event as successful received money. Ecash has to be redeemed, not just displayed.
Read NIP-61 in the wild
NIP-61 connects nutzaps to Cashu-style value. It lets social tipping explore redeemable tokens instead of every reward taking the same Lightning path.
The receipt question changes. A visible zap-like event may not tell you whether the token was redeemed, which mint backs it or whether the proof was already spent. Social display and monetary finality need separate treatment.
What changes when you actually use it
For you, NIP-61: Nutzaps is felt at the moment value moves or appears to move. The interface may show a zap, offer, wallet connection, token, invoice or result, but the source terms kind 10019, kind 9321, kind 7376, draft, event-id-1, kind:10019 decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-61: Nutzaps means separating money truth from social display. Budgets, invoices, mints, wallet services, receipts and settlement need their own status language. A delightful payment animation is harmless only after custody, limits and revocation are legible.
What the official file makes concrete
The official file is organized around High-level flow, Alice nutzaps Bob, Bob receives the nutzap, Nutzap informational event, Nutzap event, Sending a nutzap, Receiving nutzaps, Updating nutzap-redemption history. Inspect kind 10019, kind 9321, kind 7376, draft, event-id-1, kind:10019, kind:9321, relay because these are the pieces most likely to surface as product behavior. Read it beside NIP-60, NIP-65 before treating it as isolated.
NIP-61: Nutzaps needs sharper warnings than a normal social feature. Custody, invoices, receipts, budgets, mints and settlement determine whether money really moved.
Where it breaks
The failure mode in NIP-61: Nutzaps is believing the social signal more than the payment proof. A zap can be visible while settlement is incomplete, a wallet connection can outlive trust, a mint can fail, and a listing can look professional without escrow or reputation.
Where this appears outside the markdown
In the ecosystem, NIP-61: Nutzaps sits near wallets, Lightning, Cashu, offers, receipts, jobs, goals or marketplaces. These features are exciting because value becomes visible inside social context, but they are also unforgiving. A page about value has to separate the social object from the financial fact before the design turns trust into decoration.
The nearby-standard trap
The nearby-standard trap in NIP-61: Nutzaps is calling every money-adjacent event a payment. Zaps, wallet connections, Cashu proofs, nutzaps, offers, orders, goals and data jobs each prove different things. Read NIP-60, NIP-65 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-61: Nutzaps names the money state. It separates request, invoice, payment, receipt, token, mint, budget, listing, order and settlement. That is how a delightful wallet or marketplace surface stays honest.
What this page does not promise
NIP-61: Nutzaps does not turn a social signal into settled money by itself. A zap, wallet connection, listing, token, receipt or job request can be displayed beautifully while custody, settlement, refund, invoice expiry or mint risk remain unresolved. Read NIP-60, NIP-65 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-61: Nutzaps with the money state, not the animation. Identify whether kind 10019, kind 9321, kind 7376, draft, event-id-1, kind:10019 represent a request, permission, invoice, token, receipt or listing. Then read the nearby standards and source links so custody, settlement, budget and proof are not collapsed into one cheerful payment label.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-60 Cashu Wallets, Nutsack, Awesome Cashu, Sovereign Engineering projects. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-61 source is the anchor for exact wording, and NIP-61 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-60 Cashu Wallets, Nutsack, Awesome Cashu. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-61: Nutzaps: first the human promise, then kind 10019, kind 9321, kind 7376, draft, event-id-1, kind:10019, then the implementation record, then the real-world failure case. That order keeps NIP-61 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What is being proven: a request, invoice, payment, receipt, token, listing, wallet permission, mint promise or job result?
- Who can spend, revoke, refund, censor or lose the funds if the service disappears?
- Does the product separate social visibility from financial settlement before you trust the flow?
What to verify before you rely on it
- Find
kind 10019,kind 9321,kind 7376,draft,event-id-1in the official file and check where the UI exposes the same concept. - Read NIP-60, NIP-65 as context before treating NIP-61 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-61: Nutzaps in that order: Official NIP-61 source for the current wording; NIP-61 commit history for the change record; NIP-60 Cashu Wallets, Nutsack, Awesome Cashu for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
