The Fallback Address

Lightning payments are push-based — the recipient must generate an invoice before the payment can occur. If Alice wants to zap Bob's Discord account but Bob doesn't own a Lightning wallet, the standard flow fails.

The Fallback Address solves this by allowing a service to temporarily hold funds on behalf of unregistered recipients until they claim them.

The Custodial Model

When a service receives a payment request for an identifier with no connected wallet, it activates the Fallback Address flow:

1. Invoice Generation: The service generates an invoice from its own Master Node wallet.
2. Settlement: The sender pays the invoice. Funds settle to the Master Node.
3. Receipt: A Kind 5521 (Zap Receipt) or Kind 5522 (Payment Receipt) is published. The p tag is set to the connectionKey — SHA256(lidp_name:lidp_id) — which deterministically identifies the target without revealing the raw LIDP identifier.
4. Notification: If supported (e.g., via a Discord bot or Email), the service notifies the target user that funds are waiting.

The Claiming Flow

To retrieve custodial funds, the recipient must:

1. Authenticate with the LIDP (e.g., log into Discord via OAuth).
2. Bind a Nostr key — either by generating a new keypair or connecting an existing one.
3. Provide a wallet — an NWC wallet URI encrypted with NIP-44, targeted at the service's public key.
4. Verify ownership — the service decrypts the NWC URI (proving the user controls the Nostr key), verifies the LIDP identity matches the connectionKey, and sweeps the custodial funds to the user's wallet.

After claiming, subsequent payments to the same identifier will route directly to the user's wallet — the Fallback Address is no longer needed.