Zap Receipt (Kind 5521)

A Kind 5521 (Zap Receipt) is the open standard published by a Lightning Network provider after a Lightning invoice has been successfully paid.

It serves as the definitive, cryptographic proof on the Nostr network that funds were settled against a specific Zap Request.

Event Structure

The receipt is signed by the provider's key (the node that received the funds) and is published to the relays specified in the original Zap Request.

{
  "kind": 5521,
  "content": "",
  "tags": [
    ["e", "<optional_target_event_id>"],
    ["a", "<optional_kind:pubkey:d_tag>"],
    ["p", "<recipient_hex_or_ConnectionKey>", "<lidp_name>"],
    ["P", "<sender_hex_or_ConnectionKey>", "<lidp_name>"],
    ["r", "<resolved_recipient_nostr_pubkey>"],
    ["R", "<resolved_sender_nostr_pubkey>"],
    ["amount", "<payment_amount_milli_units>"],
    ["chain", "flokicoin"],
    ["bolt11", "lnfc10u1..."],
    ["description", "<json_string_of_zap_request_optional>"],
    ["preimage", "<32_byte_hex_string>"]
  ],
  "pubkey": "<provider_pubkey>",
  "created_at": "<unix_timestamp>",
  "id": "...",
  "sig": "..."
}

Required Tags

Tag	Format	Description
e	["e", "<hex>"]	Used if the Zap is in response to a specific Nostr event (copied from request).
a	["a", "<kind>:<pubkey>:<d_tag>"]	Used if the Zap is in response to a parameterized replaceable event (copied from request).
p	["p", "<hex_or_ConnectionKey>", "<lidp_name>"]	The recipient using the 3-element structure. May be appended post-settlement for Direct Payments.
P	["P", "<hex_or_ConnectionKey>", "<lidp_name>"]	The sender using the 3-element structure. This effectively supports proxy/anonymous routing.
amount	["amount", "<milli-units>"]	The payment amount extracted from the BOLT11 invoice.
chain	["chain", "<string>"]	The settled network.
bolt11	["bolt11", "<string>"]	The exact Lightning invoice that was paid.
description	["description", "<json>"]	Required. The raw JSON string of the original Kind 5520 or Kind 5523 Zap Request.
preimage	["preimage", "<hex>"]	The cryptographic proof of payment (32-byte hex string) proving the invoice was settled.

Optional Tags

Tag	Format	Description
r	["r", "<hex>"]	The true, verified Nostr pubkey of the recipient, provided by the ZSP if they resolved the p tag ConnectionKey.
R	["R", "<hex>"]	The true, verified Nostr pubkey of the sender, provided by the ZSP if they resolved the P tag ConnectionKey. Enables "Social Bridge" UX.

Identity Tag Matrix

When generating or parsing a 5521 Zap Receipt, use this matrix to correctly resolve identity tags based on the parent intent kind:

Intent Kind	Sender (P)	Recipient (p)	Resolved Recipient (r)	Resolved Sender (R)
5520	Pubkey	Pubkey OR ConnKey	If p is ConnKey	N/A (Already Pubkey)
5523	ConnKey	ConnKey	If resolved	If resolved

Standard vs. Proxy Zaps

This single Kind 5521 event covers multiple types of transactions:

1. Standard Zaps: Generated in response to a Kind 5520 Request. The description tag contains the stringified intent.
2. Proxy Zaps: Generated in response to a Kind 5523 On-Behalf Request. The description tag contains the proxy intent.

Custodial Receipts

When a payment is made via the Fallback Lightning Address model, the service holds funds temporarily on behalf of the recipient. This applies in two scenarios:

• LIDP recipients: The target has no Nostr keypair yet. The p tag contains their ConnectionKey.
• Nostr recipients: The target has a pubkey but their wallet is unreachable. The p tag contains their Nostr pubkey.

In both cases, the receipt is stored internally by the server as a pending custodial balance. When the recipient later authenticates and provides a responsive wallet, the server sweeps the funds.