Nostr Zap (NIP-57)

A Nostr Zap is a Lightning Network tip sent in response to a Nostr profile or note, standardized in NIP-57. Unlike a plain payment, a zap leaves a public, verifiable footprint on Nostr relays, so the tip is visible alongside the content it rewards. It has become the native micro-payment gesture of the Nostr ecosystem — the point where censorship-resistant speech and censorship-resistant money visibly meet.

How a zap works

The protocol defines two event kinds. A zap request (kind 9734) is an event describing the intended amount, target, and relays; the client sends it to the recipient's LNURL-pay callback rather than publishing it directly. The recipient's Lightning service, which advertises a nostrPubkey, embeds that request in a description-hash invoice. Once the invoice is paid, the service publishes a zap receipt (kind 9735) containing the bolt11 invoice and the original request, signed by the same nostrPubkey the LNURL endpoint advertised. Clients validate that the receipt's pubkey and amount match before displaying the zap. The whole flow leans on LNURL-pay plus the recipient advertising a Nostr key — usually via a human-readable Lightning Address in their profile.

Why zaps matter

Zaps replace the platform "like" with something that costs the sender real value, and that changes the signal entirely. A thousand likes are free to fake; a thousand sats are not. Creators get paid directly, peer to peer, with no platform taking a cut, no payout threshold, no account to demonetize — the value transfer works even if every large client disappeared tomorrow, because it rides on Lightning rather than on any company. Clients also support variations: anonymous zaps that omit the sender's identity, private zaps visible only to the recipient, and zap splits that divide a tip among several recipients such as a creator and their client developer. For a sovereign Bitcoiner, this is the rare social-media mechanic that aligns with first principles: value flows over open rails, attention is priced honestly, and the audience relationship is not hostage to an advertising business.

An important caveat

The specification is explicit that a zap receipt is not a proof of payment: it only proves that some party fetched an invoice and that the recipient's Lightning service chose to publish a receipt. A dishonest or buggy service could publish receipts for unpaid invoices, so treat the visible zap total as a social signal rather than a settled ledger. Client-side validation catches malformed receipts but cannot audit the Lightning service's honesty. Recipients running their own Lightning infrastructure close that gap for their own incoming zaps — one more quiet argument for self-hosting the stack.

For creators, the economics deserve a sober look. Zap revenue is instant, global, and unconfiscatable, but Lightning's fee structure makes very small tips proportionally expensive to route, and income denominated in attention is volatile on any platform. The sensible read is that zaps are less a replacement for a salary than a repricing of the social graph: they let a thousand strangers each send the equivalent of a nod that happens to be worth something, with no intermediary deciding who is allowed to be paid. That last property is the one that matters for sovereignty — demonetization, the quiet lever every centralized platform holds over its creators, simply has no equivalent here. A relay can drop your notes, but no one can stand between a willing sender and your invoice.

Zaps build directly on LNURL and a Lightning Address, and one-tap zapping is often wired through Nostr Wallet Connect so the client never holds keys. D-Central covers zaps as part of the self-custodial Nostr payment stack — the same keys-in-your-hands discipline as self-custody on the base layer, extended to social payments.