Lightning Zaps and the Public Receipt Problem
A zap is not just a tip button. It is a signed request, a Lightning invoice, a wallet response and a public receipt that changes how money and reputation appear in a social room.
The tip became a social object
Most internet payments are private database events. You pay a creator, the platform updates an internal record and maybe a badge appears. Nostr zaps make the payment trail more public. That sounds like a small UX tweak until you watch a livestream, a post, a podcast clip or a long-form article gather visible support in real time.
A zap lets money become part of the conversation. It can say thank you. It can rank a comment. It can reward a bug fix. It can signal that a post mattered enough for someone to spend real sats. It can be playful, competitive, generous or noisy. That is why zaps feel native to Nostr: they attach value to signed social activity without turning the protocol into a bank ledger.
The danger is the same as the magic. A visible payment looks like proof, but you need to know what kind of proof. A zap receipt is not a court-grade payment certificate. It is a Nostr event created by the recipient's Lightning infrastructure after an invoice tied to a zap request is paid. It is useful because clients can display it. It still needs validation.
What NIP-57 defines
NIP-57 defines two event types. A `9734` zap request represents a payer's signed request to a recipient's Lightning wallet for an invoice. A `9735` zap receipt represents confirmation by the recipient's wallet that the invoice issued in response to that request has been paid.
The flow starts with LNURL pay. A client reads the recipient's Lightning address or `zap` tag, fetches the LNURL pay endpoint and checks whether it supports Nostr zaps through `allowsNostr` and a `nostrPubkey`. If it does, the client creates a signed zap request. That request is not simply broadcast to relays. It is sent to the recipient's callback URL, which returns a Lightning invoice. After payment, the recipient's server publishes a zap receipt to the relays named in the zap request.
That chain explains why zaps sit between Nostr and Lightning rather than inside either one alone. Nostr supplies identity, signed intent, event context and relays for receipts. Lightning supplies the payment. LNURL supplies the HTTP bridge to the recipient wallet. The zap receipt makes the result visible to clients.
What a zap proves and what it does not
NIP-57 is unusually honest about proof. The zap receipt event can include the Bolt11 invoice, the description, the zap request and sometimes a preimage. But the specification warns that the receipt is not a perfect proof of payment. In practice, clients trust the recipient's LNURL server and validate the relationship between the request, invoice amount, recipient, receipt pubkey and relays.
For ordinary use, that is enough to make zaps useful. For high-value commerce, accounting or legal claims, it is not enough by itself. A merchant or creator may need wallet records, invoice IDs, settlement logs, refund policy and a clear service trail. This is why the Wallets hub separates zaps from commerce even though they overlap. A public tip and a paid contractual right are not the same thing.
The amount is usually expressed in millisatoshis inside the protocol flow, while people talk in sats. That unit boundary matters when clients display totals, leaderboards or goals. A sloppy conversion can make a page look dishonest even when the wallet behavior is fine.
Why creators love it
Zaps solve a psychological problem as much as a payment problem. A like is cheap. A comment is noisy. A subscription is a larger commitment. A zap sits in the sweet spot: small enough to be casual, real enough to matter, visible enough to create energy. It lets fans reward a specific post instead of only paying for a whole membership.
For musicians, writers, streamers, educators and independent journalists, that changes the feedback loop. A good explainer can receive sats without a paywall. A live room can light up when a guest says something sharp. A small community can fund maintenance without waiting for a sponsor. A niche creator can see which posts actually moved people.
The same mechanism can become performance. Leaderboards, zap goals and public totals invite games. That can be fun. It can also distort incentives. A creator may chase zap-visible content over slower work. A community may start measuring seriousness by sats alone. A good product surface should celebrate support without pretending money is the only signal.
Spam, status and the weird good part
NIP-57 explicitly mentions fun and spam deterrence. That second word is important. When a payment is attached to a message, low-effort spam becomes more expensive. Not impossible, but costlier. Paid comments, paid DMs and zap-weighted visibility are one way communities experiment with attention markets without asking a central platform to decide every ranking rule.
That does not make zaps pure. Money can buy attention. Wealthy users can dominate rooms. Coordinated groups can manufacture status. Scam projects can collect visible payments to look credible. A zap tells you that value moved through a specific infrastructure path; it does not tell you that the recipient is trustworthy or the content is true.
The useful stance is neither cynical nor naive. Treat zaps as one signal among many: identity, history, relay context, reputation, source links, wallet trail and community memory still matter.
Product decisions that make zaps feel safe
A good zap UI answers four questions quickly. Who receives the payment? What event or profile is being zapped? Which wallet will pay? What public information will appear afterwards? The client should make the amount, comment, sender identity and recipient clear before the wallet sends money.
If the payment uses NWC, the wallet connection needs a budget that matches the behavior. Tiny zap allowances are useful. Large unlimited zap permissions are not. If the payment goes through a Lightning address, the client should explain when the address does not support Nostr receipts and when a normal Lightning payment will not become a visible zap.
For Crays-style creator tools, zaps become even more interesting when they sit beside paid posts, awards, voting games, fan rooms and direct sales. The product should not blur them. A zap can be support. A paid access purchase can be a right. A vote can be a game mechanic. A creator needs to know which one happened.
Where to go next
Read NIP-57 when you need the exact request and receipt mechanics. Open Lightning Address and LNURL material when you want the address and callback layer. Open NIP-47 when a client pays zaps through a remote wallet connection. Then look at real products: Alby, Primal, Damus, Amethyst, zap.stream, Wavlake and other clients show how the same concept feels different in different rooms.
The practical habit is simple: never read a zap as one thing. Read the request, the invoice, the receipt, the client display and the social context. That is where the small-money internet becomes useful instead of just loud.
A zap is a chain, not a lightning-shaped like
NIP-57 is useful because it forces you to see the chain. The client starts with a profile Lightning address or zap tag, fetches the LNURL pay endpoint, checks whether the endpoint supports Nostr through allowsNostr and nostrPubkey, creates a signed kind 9734 zap request, sends that request to the callback URL, receives a Lightning invoice, pays it and then waits for the recipient's infrastructure to publish a kind 9735 receipt to the relays named in the request.
That is not trivia. Every step can break in a different way. The address can be stale. The LNURL endpoint can support normal payments but not Nostr receipts. The invoice can expire. The wallet can fail to pay. The recipient server can validate the request but fail to publish the receipt. The relay can miss it. A good zap product should let you understand which part failed, because each failure changes what the social interface should claim.
The best zap UX feels instant, but the article has to keep the chain visible. Instant does not mean simple. It means the product hid several systems well enough that the user could stay in the conversation.
The receipt is public memory with wallet-shaped limits
A zap receipt is powerful because it leaves a social memory of value moving. It can light up a post, reward a clip, rank a reply or make a livestream feel alive. But the receipt lives at the crossing of Nostr and Lightning. It is signed and relay-visible, yet it depends on wallet infrastructure outside the relay network.
This is why the receipt should be read as strong social evidence, not complete accounting. A creator can use it to show public support. A client can use it to rank or celebrate. A merchant should still keep invoice, order and settlement records elsewhere. The more a product turns zaps into access, entitlement, voting weight or legal obligation, the more it needs a private business record beside the public receipt.
That distinction keeps the feature from being overburdened. Zaps are excellent for support, attention and small feedback loops. They are weaker when a page silently treats them as audited revenue, contractual purchase or identity proof.
Zaps need different words in different rooms
The same zap can feel different depending on where it lands. On a microblog post it is thanks. In a live room it is applause. In a music app it is value-for-value. On a bounty it may be funding. On a leaderboard it becomes status. On a paid article it might be confused with access. The protocol does not decide that meaning; the product does.
So the product language has to be unusually precise. Tip, boost, payment, vote, donation, bounty, unlock, sponsorship and purchase are not synonyms. If a user spends sats, the interface should say what social meaning the payment will carry and what practical right, if any, it creates. This is especially important for Crays-style awards, creator profiles and fan rooms where public money can become reputation very quickly.
Good zaps stay playful without becoming vague. They show recipient, amount, event context, public comment, wallet used and receipt state. Then they let the community decide what the gesture means instead of pretending the protocol can settle the social story by itself.
Where zaps still feel early
The current zap ecosystem is alive but uneven. Some clients surface receipt validation clearly. Some mostly show totals. Some wallet flows publish receipts reliably. Others make payment and visible proof drift apart. Some products experiment with moving Lightning address data out of broad profile metadata into more specialized discovery events. That experimentation is healthy, but it means zap pages should avoid sounding finished.
The honest posture is practical: enjoy zaps as the small-money social primitive they are, and check the surrounding wallet, relay and product records before assigning heavier meaning to them.
Sources worth opening
Open these when you want the specification, product documentation or implementation trail behind the article.
- NIP-57: Lightning Zaps
- Lightning Address
- LNURL LUD-06
- Nostr Wallet Connect
- CLN Nostr zapper implementation
- Wavlake NIP-57 address-refactor discussion
- NWC docs for wallet-driven zap flows
