Skip to main content

The Fallback Address

To achieve the goal of "Zapping Anyone, Anywhere," Zapf must solve a fundamental UX problem: Lightning payments are push-based and require the recipient to generate an invoice before the payment can occur.

If Alice wants to zap bob@discord, but Bob has never heard of Zapf and doesn't own a Lightning wallet, the standard protocol fails.

The Fallback Address is Zapf's solution to this limitation.

The Custodial Proxy Model​

When a Zapf IA detects a payment request directed at an unregistered identifier, it utilizes the Fallback Address architecture:

  1. Interception: Instead of failing the LNURL lookup, the IA responds with its own Master Node lightning address.
  2. Escrow: The sender pays the invoice, and the funds settle instantly to the Zapf Master Node.
  3. Custodial Receipt: The IA generates a standard Zap Receipt (Kind 5521) or Payment Receipt (Kind 5522). However, in these custodial receipts, the p tag (the recipient) targets the raw hash of the LIDP identifier (e.g., SHA256("discord:12345")), rather than a user's Nostr pubkey.
  4. Notification: If the IA has the capability (e.g., via an Email or Discord bot), it notifies the target user that funds are waiting for them.

The Claiming Flow​

To retrieve escrowed funds, the recipient must execute the Claiming Flow:

  1. Login: The user authenticates with the LIDP (e.g., logs into Discord via OAuth).
  2. Key Generation: The client generates a Nostr keypair for the user (or the user connects their existing extension).
  3. Stateless Prove: The user connects a destination NWC wallet and encrypts the NWC URI using NIP-44, targeted solely at the IA's public key.
  4. Sweep: The IA decrypts the NWC string—cryptographically proving the user owns the Nostr pubkey. The IA then scans its ledger for any custodial receipts matching the user's unified LIDP hash, and automatically sweeps the funds out of its Master Node directly into the user's personal NWC wallet.

The r Tag Routing Mechanism​

To maintain NIP-57 compliance while handling custodial funds, Zapf utilizes an internal routing tag.

When a custodial Kind 5521 Zap Receipt is published, the p tag technically points to the Zapf Server's own pubkey (as it legally holds the funds). An additional r tag is appended: ["r", "<identifier_hash>", "provider_name"]. This ensures the protocol remains strictly compliant with Nostr relay indexing rules while allowing the internal system to attribute the pool of funds correctly during the sweeping phase.