1 files changed, 13 insertions, 1 deletions

diff --git a/57.md b/57.md
index 7887652..17042ea 100644
--- a/57.md
+++ b/57.md
@@ -12,7 +12,7 @@ Having lightning receipts on nostr allows clients to display lightning payments
 
 ## Protocol flow
 
-1. Client calculates a recipient's lnurl pay request url by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
+1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
 2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a zap receipt rather than a normal lnurl invoice.
 3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it.
 4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example.
@@ -166,6 +166,18 @@ A client can retrieve `zap receipts` on events and pubkeys using a NIP-01 filter
 - The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present).
 - The `lnurl` tag of the `zap request` (if present) SHOULD equal the recipient's `lnurl`.
 
+### Appendix G: `zap` tag on zapped event
+
+When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on it's value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`.
+
+```json
+{
+    "tags": [
+        [ "zap", "pablo@f7z.io", "lud16" ]
+    ]
+}
+```
+
 ## Future Work
 
 Zaps can be extended to be more private by encrypting zap request notes to the target user, but for simplicity it has been left out of this initial draft.