diff --git a/57.md b/57.md
index 91eac30655..74fa4c0168 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 from the `zap` tag on the event being zapped (see Appendix G), or by decoding their 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 `lud16` tag from kind `10057` 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.
@@ -186,6 +186,19 @@ When an event includes one or more `zap` tags, clients wishing to zap it SHOULD
 
 Clients MAY display the zap split configuration in the note.
 
+### Appendix H: Setting up receving ln addresses 
+
+Users MUST declare their lightning addresses on kind `10057` to receive zaps.
+
+{
+  "kind": 10057,
+  "tags": [
+    ["lud16", "someone@provider.com"],
+    ["lud16", "someone@provider2.com"],
+  ],
+  // other fields...
+}
+
 ## 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.