Glossary

Zap (Lightning Tip)

A zap is a Lightning Network micropayment sent through the Nostr social protocol to tip content creators instantly.

Key Takeaways

  • A zap is a micropayment sent over the Lightning Network through the Nostr social protocol, enabling one-click tipping for content creators.
  • Zaps are defined by NIP-57, which uses two event kinds: kind 9734 (zap request) and kind 9735 (zap receipt). The protocol relies on LNURL servers and Lightning invoices to process payments.
  • Zaps implement the value-for-value model: instead of monetizing through ads, creators receive direct Bitcoin payments from their audience with no platform intermediary taking a cut.

What Is a Zap?

A zap is a Lightning Network payment attached to a social event on the Nostr protocol. When a user sees a post they appreciate, they can send a small Bitcoin payment directly to the author with a single click. The payment amount, sender, and optional message are recorded as a Nostr event, making the tip visible to the entire network.

The term "zap" was introduced alongside NIP-57, authored by William Casarin (creator of the Damus client) in February 2023. The specification defines how Nostr clients coordinate with Lightning wallets and LNURL servers to create a seamless tipping experience. By May 2025, the Nostr network had processed over 5 million zaps.

Zaps represent a fundamental shift in social media monetization. Traditional platforms sell user attention to advertisers; zaps let audiences compensate creators directly. Because Lightning enables near-zero-fee micropayments, a zap can be as small as a single satoshi, making micro-tipping practical in a way that credit card rails cannot support.

How It Works

The zap protocol involves coordination between three systems: the sender's Nostr client, the recipient's LNURL server, and the Lightning Network itself. The process uses two Nostr event kinds: kind 9734 for the zap request and kind 9735 for the zap receipt. The receipt's kind number (9735) was intentionally chosen to match Lightning Network's default port number.

  1. The sender's client reads the recipient's Nostr profile to find their Lightning address (the lud16 field) and resolves it to an LNURL pay endpoint
  2. The client sends a GET request to the LNURL endpoint. If the response includes allowsNostr: true and a nostrPubkey field, the client displays the zap button
  3. When the sender clicks zap, the client creates and signs a kind 9734 zap request event containing the recipient's pubkey, relay list, amount, and an optional message
  4. The client sends this event (URI-encoded JSON) to the recipient's LNURL callback URL as the nostr query parameter, along with the amount in millisatoshis
  5. The recipient's LNURL server validates the zap request (checks signature, tag structure, amount match) and generates a description-hash Lightning invoice where the description is the zap request JSON
  6. The sender's client pays the invoice, either directly or by passing it to a connected Lightning wallet
  7. Upon payment confirmation, the recipient's LNURL server constructs a kind 9735 zap receipt event and publishes it to the relays specified in the original zap request
  8. Other clients query relays for kind 9735 events, validate them against the LNURL server's public key, and display the zap on the relevant post or profile

Zap Request Structure (Kind 9734)

The zap request event is created by the sender's client but never published to relays directly. Instead, it is sent to the recipient's LNURL server via HTTP. The event includes the following tags:

{
  "kind": 9734,
  "content": "Great post!",  // optional message
  "tags": [
    ["relays", "wss://relay.damus.io", "wss://nos.lol"],
    ["p", "<recipient-hex-pubkey>"],
    ["e", "<event-id>"],      // if zapping a specific note
    ["amount", "21000"],      // millisatoshis
    ["lnurl", "<bech32-lnurl>"]
  ]
}

Zap Receipt Structure (Kind 9735)

The zap receipt is created and signed by the recipient's LNURL server (not the sender or recipient themselves). It serves as a public record that the payment occurred:

{
  "kind": 9735,
  "content": "",
  "tags": [
    ["p", "<recipient-hex-pubkey>"],
    ["P", "<sender-hex-pubkey>"],
    ["e", "<event-id>"],
    ["bolt11", "<lightning-invoice>"],
    ["description", "<json-encoded-9734-event>"],
    ["preimage", "<payment-preimage>"]
  ]
}

Clients validate zap receipts by checking that the receipt's signing pubkey matches the nostrPubkey from the recipient's LNURL endpoint and that the invoice amount matches the amount in the zap request.

Types of Zaps

NIP-57 supports several zap visibility modes:

  • Public zaps: the sender, amount, and message are all visible on the post. This is the default and most common type.
  • Anonymous zaps: the amount is visible, but the sender's identity is hidden. The client creates the zap request with a randomly generated key pair and discards it after sending.
  • Private zaps: completely hidden from public view. Only the sender and recipient know the payment occurred.

Nostr Wallet Connect

The biggest UX barrier to zapping is wallet connectivity. Without a seamless link between a Nostr client and a Lightning wallet, each zap requires manually copying and paying an invoice. Nostr Wallet Connect (NWC), defined in NIP-47, solves this by creating an encrypted communication channel between client and wallet over Nostr relays.

NWC uses a connection URI containing the wallet's public key, a relay URL, and a shared secret. Once connected, the Nostr client can request invoice payments directly from the wallet without manual intervention. Wallet owners set spending budgets and method restrictions per connection, and each app gets its own revocable connection secret.

Compatible wallets include Alby (via browser extension or Alby Hub), Wallet of Satoshi, Primal Wallet, Zeus, LNbits, and Coinos. Primal's built-in wallet removes the setup step entirely, providing a one-tap zap experience without external wallet configuration.

The Value-for-Value Model

Zaps are the practical implementation of the "value for value" (V4V) model, a philosophy that gained traction through the Podcasting 2.0 movement. The core idea: instead of giving away attention for free to advertisers, users directly support creators with real economic value.

Traditional social media optimizes for engagement farming through outrage and clickbait because platforms earn revenue from ad impressions, not content quality. Zaps flip this incentive structure: content that people find genuinely valuable receives direct monetary support. There is no intermediary platform taking a 30% cut, no minimum payout threshold, and no geographic restrictions.

The V4V model extends beyond social posts. Podcasting apps like Fountain let listeners stream sats per minute to podcasters using the Podcasting 2.0 podcast:value RSS tag. This streaming payment model is only practical on Lightning, where the marginal cost per transaction approaches zero. For more on how Bitcoin enables creator payments, see Creator Economy Payments.

Zap Splits

NIP-57 supports splitting zap payments among multiple recipients. Events can include multiple zap tags, each specifying a receiver pubkey and an optional weight parameter. When a user zaps a collaborative post, the client calculates each recipient's share based on their weight and generates separate zap requests accordingly.

Use cases for zap splits include co-authored articles, podcast co-hosts, music collaborations, and any content with multiple contributors. If weights are not specified, the payment divides equally among all recipients.

Use Cases

Content Creator Tipping

The primary use case for zaps is tipping content on Nostr. Writers, artists, and developers publish posts and receive instant payments from appreciative followers. Unlike traditional tipping platforms that require minimum balances and take percentage cuts, zaps deliver 100% of the payment to the creator via Lightning. The public nature of zap receipts also serves as social proof, signaling quality content to other users.

Podcast and Media Streaming

Value-for-value podcasting uses Lightning to stream micropayments to creators in real time. Listeners set a per-minute streaming rate, and their wallet sends continuous small payments while they listen. One-time "boosts" with messages function like super-chats, allowing listeners to send larger amounts with attached notes.

Crowdfunding and Zap Goals

Nostr clients support "zap goals" where creators set funding targets for specific projects. The community can track progress toward the goal in real time, with each zap visibly moving the total closer to the target. This creates a decentralized crowdfunding mechanism without requiring a platform like Kickstarter or Patreon.

Relay and Infrastructure Funding

Nostr relay operators can receive zaps to fund infrastructure costs. This creates a direct economic relationship between users who benefit from reliable relay service and the operators who provide it, though adoption remains uneven: most relays currently receive few or no zaps.

NIP-61: Nutzaps (Ecash Alternative)

NIP-61, merged in late 2024, introduces an alternative zapping mechanism using Cashu ecash tokens instead of Lightning invoices. Called "nutzaps," these payments embed bearer tokens directly in Nostr events, eliminating the LNURL round-trip entirely.

With nutzaps, the sender mints ecash tokens at one of the recipient's trusted Cashu mints, locks them to the recipient's public key, and publishes a kind 9321 event containing the token proofs. The recipient redeems the tokens into their wallet. The key advantage: the payment itself is the receipt, requiring no Lightning infrastructure for the zap event and providing instant settlement. For more on ecash, see Ecash and Chaumian Mints on Bitcoin.

Spark and the Zap Ecosystem

Any Lightning-compatible wallet can participate in the zap ecosystem by connecting to a Nostr client via Nostr Wallet Connect or LNURL. Spark-compatible wallets, built on Spark's Bitcoin Layer 2, can send and receive zaps through the same Lightning infrastructure. Because Spark supports instant, low-fee Bitcoin transfers, it provides a natural fit for the micropayment patterns that zaps require.

Risks and Considerations

Trust in LNURL Servers

Zap receipts are not cryptographic proofs of payment. The receipt only indicates that the recipient's LNURL server claims an invoice was paid. Users must trust the server to honestly report payments. A compromised or malicious LNURL server could fabricate zap receipts or fail to generate them for legitimate payments.

Wallet Setup Friction

Sending and receiving zaps requires a Lightning wallet connected to a Nostr client, plus a Lightning address configured in the user's profile. While solutions like Primal's built-in wallet and NWC have reduced friction, the setup process remains a barrier for non-technical users. Roughly 82.5% of Nostr profiles now include Lightning addresses, but the gap between having an address and actively using zaps remains significant.

Custodial Risks

Many popular zap-compatible wallets (such as Wallet of Satoshi) are custodial, meaning the wallet provider holds users' funds. If the provider goes offline, restricts service, or is compromised, users could lose access to their sats. Self-custodial alternatives like Alby Hub offer more control but require greater technical setup. For a comparison of custody models, see Self-Custodial vs. Custodial Wallets.

Privacy Trade-offs

Public zaps reveal sender identity, recipient, amount, and message to anyone who can read Nostr relays. While anonymous and private zap modes exist, the default public mode creates a visible trail of financial activity. Users should be aware that their zapping patterns are observable and potentially analyzable.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.