Zap Receipt (Kind 5521)

A Kind 5521 (Zap Receipt) is published by a Lightning Network provider (often the Zapf Identity Authority itself) 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": [
    ["p", "<recipient_pubkey>"],
    ["P", "<sender_pubkey>"],
    ["e", "<optional_target_event_id>"],
    ["bolt11", "lnbc10u1..."],
    ["description", "<json_string_of_zap_request>"],
    ["preimage", "<32_byte_hex_string>"],
    ["r", "<lidp_identifier_hash>", "<lidp_name>"] 
  ],
  "pubkey": "<provider_pubkey>",
  "created_at": 1709424005,
  "id": "...",
  "sig": "..."
}

Required Tags

Tag	Format	Description
p	["p", "<hex>"]	The recipient of the funds. Must match the p tag from the Zap Request.
P	["P", "<hex>"]	Originating from NIP-57, this is the pubkey of the Sender (extracted from the Zap Request).
bolt11	["bolt11", "<string>"]	The exact Lightning invoice that was paid.
description	["description", "<json>"]	The raw JSON string of the original Kind 5520 Zap Request.
preimage	["preimage", "<hex>"]	The cryptographic proof of payment (32-byte hex string) proving the invoice was settled.

The Custodial r Tag

One of Zapf's key innovations is the Fallback Address model. When a payment is made to a user who doesn't have a wallet, the funds settle to the IA's Master Node.

To maintain NIP-57 compliance:

1. The p tag in the receipt will reflect the Zapf Server's own pubkey (since the Zapf server legally holds the funds at that moment).
2. The IA appends a custom r (Route) tag: ["r", "fb17c...hash", "discord"].

This r tag tells the Zapf backend logic exactly which internal virtual ledger account to credit with the funds, allowing that specific Discord user to claim the funds later.