Kind 9734: Zap Request

Overview

Zap Request events (kind 9734) are special events that are not published to relays but are instead sent to a recipient's LNURL pay service to request a Lightning Network invoice. They represent a user's intention to send a Bitcoin payment (zap) to another user or to a specific Nostr event. When a zap request is processed and the resulting invoice is paid, the service generates a Zap Receipt (kind 9735) that gets published to relays.

Specification

Property	Value
Kind Number	9734
Event Range	Regular (but not published to relays)
Defined in	NIP-57

Content Format

The content field may contain an optional message to accompany the zap payment. This serves as a comment or note from the sender to the recipient.

Schema

"Optional message to accompany the zap payment"

Tags

Tag Name	Description	Format	Required
relays	Relays where the zap receipt should be published	["relays", "wss://relay1.com", "wss://relay2.com"]	Yes
amount	Amount in millisatoshis to pay	["amount", "21000"]	Recommended
lnurl	Recipient's LNURL in bech32 format	["lnurl", "lnurl1..."]	Recommended
p	Recipient's public key	["p", "<pubkey-hex>"]	Yes
e	Event being zapped (if applicable)	["e", "<event-id>", "<relay-url>"]	No
a	Addressable event coordinate (if applicable)	["a", "<kind>:<pubkey>:<d-tag>"]	No

Client Behavior

Clients should:

1. Not publish zap request events to relays - they are only sent to the recipient's LNURL service.
2. Create and sign zap requests when users want to send zaps.
3. Encode the zap request as a URI parameter in the HTTP GET request to the LNURL callback endpoint.
4. Include the essential tags: relays, p, and optionally e or a when zapping specific content.
5. Receive the invoice from the LNURL service and facilitate payment.
6. Handle the returned lightning invoice through appropriate wallet integration.
7. Support zapping both profiles and specific events.

Relay Behavior

Since zap request events are not intended to be published to relays, there is no specific relay behavior for them.

Use Cases

• Requesting a lightning invoice to tip a user
• Requesting a lightning invoice to reward a specific post
• Attaching a comment to a lightning payment
• Directing where the corresponding zap receipt should be published
• Supporting multiparty (split) payments when zapping events with multiple zap tags

Example

{
  "kind": 9734,
  "content": "Great post, thanks for sharing!",
  "tags": [
    ["relays", "wss://nostr-pub.wellorder.com", "wss://relay.damus.io"],
    ["amount", "21000"],
    ["lnurl", "lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp"],
    ["p", "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"],
    ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"]
  ],
  "pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
  "created_at": 1679673265,
  "id": "30efed56a035b2549fcaeec0bf2c1595f9a9b3bb4b1a38abaf8ee9041c4b7d93",
  "sig": "f2cb581a84ed10e4dc84937bd98e27acac71ab057255f6aa8dfa561808c981fe8870f4a03c1e3666784d82a9c802d3704e174371aa13d63e2aeaf24ff5374d9d"
}

HTTP Request Format

When sending a zap request to a recipient's LNURL callback URL, the request should have the following format:

GET <callback-url>?amount=21000&nostr=<URI-encoded-zap-request>&lnurl=<bech32-lnurl>

References

• NIP-57: Lightning Zaps
• LNURL specification
• LUD-06: payRequest base spec

Related Kinds

• Kind 9735: Zap Receipt - Confirmation of a paid zap invoice
• Kind 9041: Zap Goal - Fundraising campaign with zaps

Notes

• Zap requests must be validated by the recipient's LNURL server before generating an invoice.
• The LNURL server must support Nostr zaps, which is indicated by allowsNostr: true in the LNURL-pay response.
• The server's nostrPubkey field indicates which public key will be used to sign the resulting zap receipt.
• Zap requests can be used with events that have multiple zap tags to distribute a payment among multiple recipients.
• In the future, encrypted zap requests may be implemented for increased privacy.