NIP-57: Lightning Zaps
Zaps turned Nostr culture into a payment surface
Before NIP-57, a Nostr post could mention Lightning, but the payment was outside the social object. NIP-57 ties the social action and the Lightning payment together. A user can zap a profile or event, and clients can show a signed receipt proving the recipient's wallet saw the paid invoice.
That is why zaps became cultural. They are tips, applause, spam deterrence, funding signals, comments, social proof and tiny economic votes. They also gave Nostr something many social protocols lack: money moving at the speed of conversation.
NIP-57 is not a wallet protocol by itself. It is a receipt and request standard built around LNURL Pay. Wallets, clients and relays each do a piece.
Zap requests, invoices and receipts
A zap request is kind 9734. It is signed by the sender but not published to relays. Instead, the client sends it to the recipient's LNURL callback. The request includes relays where the receipt needs to be published, amount, recipient, optional event or address references and optional content as a zap comment.
The recipient's LNURL server validates the request, returns an invoice and, after payment, publishes a zap receipt of kind 9735 to the requested relays. Clients verify receipts by checking the payment request, description hash or related proof rules, recipient pubkey and the embedded request.
The standard also supports zap splits through zap tags and weights, plus event-specific markers. This lets a post, stream or project split incoming zaps across several recipients.
A busy file because zaps became real very quickly
William Casarin added the visible NIP-57 work in February 2023. Jonathan Staab rewrote it in March 2023 to consolidate terminology and flow. Vitor Pamplona added zap splits and client-guidance changes in May 2023. Pablo Fernandez added indexable zap senders with a capital P tag in January 2024.
Later changes clarified description tags, description-hash verification, missing k tags and removed a lud06 field. The file has many small edits because zaps are deployed in real clients, wallets and LNURL servers. Tiny ambiguity becomes visible when money is involved.
NIP-57 is therefore one of the standards where implementation history matters as much as the final text.
The receipt is only useful if clients verify it
Damus, Primal, Amethyst, Alby-connected clients, zap.stream and many Nostr apps expose zaps. Alby and Nostr.how both provide user-facing guidance for setting up zap-capable Lightning addresses. On the wallet side, LNURL support and Nostr-aware metadata are the bridge.
The implementation danger is fake or weakly checked receipts. A client needs to not display any kind 9735 as a real payment just because it exists. It needs to verify the receipt against the request, amount, recipient, invoice and wallet pubkey expectations.
A good zap UI shows amount, sender when public, recipient, target note or profile, comment and verification state. It needs to also handle privacy. Not every payer wants every payment to become a public social badge.
Money makes social signals louder
Zaps can reward good work. They can also amplify popularity games, spam, harassment or paid attention. A public payment is a social signal, and social signals can be manipulated.
There is also a privacy boundary. A zap can link a wallet, a social key, a note, an amount and a timestamp. Clients and wallets needs to make public versus private behavior clear before a user pays.
Read NIP-57 in the wild
NIP-57 made zaps a social money primitive. A Lightning payment can carry a signed Nostr request and produce a receipt connected to a person, note or addressable event.
The magic is also the risk: people read zaps as appreciation, proof, ranking and money. A client needs to separate payment settlement, social display and what the receipt actually proves.
What changes when you actually use it
For you, NIP-57: Lightning Zaps 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 9734, draft, zap request, zap receipt, zap, true decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-57: Lightning Zaps 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 Protocol flow, Reference and examples, Appendix A: Zap Request Event, Appendix B: Zap Request HTTP Request, Appendix C: LNURL Server Configuration, Appendix D: LNURL Server Zap Request Validation, Appendix E: Zap Receipt Event, Appendix F: Validating Zap Receipts. Inspect kind 9734, draft, zap request, zap receipt, zap, true, nostrPubkey, minSendable because these are the pieces most likely to surface as product behavior. Read it beside NIP-23, NIP-01 before treating it as isolated.
NIP-57: Lightning Zaps 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-57: Lightning Zaps 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-57: Lightning Zaps 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-57: Lightning Zaps 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-23, NIP-01 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-57: Lightning Zaps 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-57: Lightning Zaps 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-23, NIP-01 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-57: Lightning Zaps with the money state, not the animation. Identify whether kind 9734, draft, zap request, zap receipt, zap, true 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: LNURL LUDs, Alby zaps guide, Nostr.how zaps guide, Damus GitHub repository. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-57 source is the anchor for exact wording, and NIP-57 commit history shows how that wording moved over time. The strongest secondary clues here are LNURL LUDs, Alby zaps guide, Nostr.how zaps guide. 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-57: Lightning Zaps: first the human promise, then kind 9734, draft, zap request, zap receipt, zap, true, then the implementation record, then the real-world failure case. That order keeps NIP-57 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 9734,draft,zap request,zap receipt,zapin the official file and check where the UI exposes the same concept. - Read NIP-23, NIP-01 as context before treating NIP-57 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-57: Lightning Zaps in that order: Official NIP-57 source for the current wording; NIP-57 commit history for the change record; LNURL LUDs, Alby zaps guide, Nostr.how zaps guide 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.
