From 9c97736066a131442a5e43420f0600904959d1cf Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Wed, 24 May 2023 10:10:18 -0400 Subject: [PATCH] minor text/grammar adjustments --- 57.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/57.md b/57.md index 4d02611d..a2214817 100644 --- a/57.md +++ b/57.md @@ -168,7 +168,7 @@ A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter ### Appendix G: `zap` tag on zapped event -When an event includes one or more `zap` tags, clients SHOULD calculate the lnurl pay request based on their value instead of the profile's field. The tag's second argument is a `lud06` address, `lud16` identifier or `hex` string of the receiver's pub key. An optional third argument specifies the type of the previous value: `lud06`, `lud16` or `pubkey`. An optional fourth parameter specifies the weight (a generalization of a percentage) assigned to the respective receiver. Clients should parse all weights, calculate a sum, and then a percentage to each member. If weights are not present, CLIENTS should equally divide the zap amount to all zap receivers. If weights are only partially present, receivers without a weight should not be zapped (`weight = 0`). +When an event includes one or more `zap` tags, clients SHOULD calculate the lnurl pay request based on their value instead of the profile's field. The tag's second argument is a `lud06` address, a `lud16` identifier or a `hex` string of the receiver's pub key. An optional third argument specifies the type of the previous value: `lud06`, `lud16` or `pubkey`. An optional fourth parameter specifies the weight (a generalization of a percentage) assigned to the respective receiver. Clients should parse all weights, calculate a sum, and then a percentage to each receiver. If weights are not present, CLIENTS should equally divide the zap amount to all receivers. If weights are only partially present, receivers without a weight should not be zapped (`weight = 0`). ```json {