Skip to main content

On-Behalf Zap Request (Kind 5523)

As an extension to the open protocol ecosystem, Kind 5523 (On-Behalf Zap Request) is a specialized variant of the standard NIP-57 ↗ Zap Request (Kind 5520). It was introduced by the Zap Protocol to securely support "proxy" or "custodial" zaps made on behalf of external, off-chain users by Proxy Agents (e.g., Tipf bots).

Standard NIP-57 ↗ assumes that the pubkey signing the Zap Request is the literal economic sender of the funds. When a custodial bot—such as a proxy Tipf application—generates a Zap Request, standard Nostr clients can incorrectly attribute the funds or social signal to the bot itself rather than the true user.

Kind 5523 solves this semantic ambiguity by enforcing that aware clients must ignore the event pubkey and strictly inspect the p (Recipient) and P (Sender) tags to ascertain the correct connection identities.

Structure​

The event generally maps 1:1 with the standard Kind 5520 structure, except for its specific kind identifier (5523) and its rigid expectation that the attribution tags will utilize 3 elements instead of 2.

{
  "kind": 5523,
  "content": "Sent via Proxy Application",
  "tags": [
    ["p", "<recipient_ConnectionKey>", "<lidp_name>"],
    ["P", "<sender_ConnectionKey>", "<lidp_name>"],
    ["amount", "100000"],
    ["chain", "flokicoin"],
    ["relays", "wss://relay.zapf.app", "wss://relay.damus.io"],
    ["lnurl", "lnurl..."]
  ],
  "pubkey": "<tipf_server_identity>",
  "created_at": 1709424000,
  "sig": "..."
}

Tag Explanations​

  • p (Recipient): Instead of a raw Nostr pubkey, this tag expects [ "p", "<hex_or_hash>", "<lidp_name>" ].
  • P (Sender): Instead of a raw Nostr pubkey, this tag expects [ "P", "<hex_or_hash>", "<lidp_name>" ].
  • amount: Requested strictly in mloki or msats (milli-units).
  • chain: Required context. Must be flokicoin or bitcoin.

Verification & Parsing​

  1. ZSP Integration: The Zap Settlement Provider (ZSP) seamlessly respects 5523 alongside 5520 via its LNURL-Pay webhook callback, ensuring identical amount verification and wrapping the 5523 string seamlessly inside the resulting 5521 (Zap Receipt) description tag.
  2. Client UI Resolution: The Nostr client parses the description tag. Upon detecting a 5523 event, it invokes a network query for Kind 35521 using the #d filter (<ConnectionKey>). This permits the UI to translate the external ConnectionKey back into a native Nostr Kind 0 profile metadata object dynamically. If the identity connection query returns nothing, the UI displays the Fallback LIDP profile data (e.g., Provider Avatar) returned by the ZSP implementation's API.