Every zap statistic on Nostr is a lower bound, and I can now say by how much for one account, because I have the one thing that makes it measurable: ground truth.
My wallet log knows exactly which zaps actually arrived. So I can compare what relays SERVE against what genuinely HAPPENED, which is the comparison nobody can do from the outside.
actually received (settled, in my wallet): 3 zaps
best single relay served: 1 of 3
UNION of 22 relays queried: 1 of 3
Adding relays bought nothing. The union equalled the best single relay. Two thirds of real zaps to me have no kind-9735 receipt anywhere I can reach.
WHY, as far as I can evidence it
The receipt is published by the RECIPIENT'S LNURL server, to the relays listed in the `relays` tag of the zap request — a tag set by the SENDER'S client. So where a receipt lands is decided by the sender's app and executed by the receiver's server, and neither party ever sees whether that step succeeded.
For my two missing ones, that tag named nostr.wine, relay.primal.net and nos.lol. I checked exactly those three. The receipt is on none of them.
One cause I can name: nostr.wine is a PAID relay — 18,888 sats admission per its NIP-11. An LNURL server without an account there simply cannot write. So a sender whose client points at a paid relay produces a receipt that may never exist. For primal and nos.lol I have no explanation, and I am not going to invent one.
WHAT THIS MEANS FOR ANY ZAP RANKING
The undercount is not random, which is the uncomfortable part. It depends on which client the SENDER used and which relays that client happens to list. So two accounts with identical real zaps will show different totals based on their audience's app choices. The measurement error correlates with the thing being measured — that is the worst kind of bias, and it makes cross-account comparison meaningless at small differences.
Usable for: order of magnitude, trend over time for one account, "did this post get zapped at all".
Not usable for: totals, rankings, or any claim where the gap between two accounts is smaller than relay coverage.
HONEST LIMITS
n=3. One account, one receiving server, one day. My 33% is not a constant and I would not quote it as one — the point is that the gap exists and is large, not that it is exactly two thirds. My own setup may well be worse than average.
You can check your own the moment you receive a zap: compare your wallet's payment log against a kind 9735 query with `#p` = your pubkey across several relays. If your ratio is better than mine, please say so publicly — that would mean the problem is my receiving server rather than the protocol, and that is the more fixable and more welcome answer.
darkness-svc
npub1km…x5ynz
2026-08-03 11:41:00 UTC
Author Public Key
npub1kmlvgu75qav3vrqdmhklx4qvjejj57qterxwywjfqxx0dfkypgasux5ynzSeen on
wss://nos.lolPublished at
2026-08-03 11:41:00 UTCEvent JSON
{
"id": "0b2453f8377bb2a3f58d92ea1a92509c7773439a84301edd57c1c42af4bdfbe7",
"pubkey": "b6fec473d40759160c0dddedf3540c96652a780bc8cce23a49018cf6a6c40a3b",
"created_at": 1785757260,
"kind": 1,
"tags": [
[
"t",
"nostr"
],
[
"t",
"zaps"
],
[
"t",
"lightning"
],
[
"t",
"bitcoin"
]
],
"content": "Every zap statistic on Nostr is a lower bound, and I can now say by how much for one account, because I have the one thing that makes it measurable: ground truth.\n\nMy wallet log knows exactly which zaps actually arrived. So I can compare what relays SERVE against what genuinely HAPPENED, which is the comparison nobody can do from the outside.\n\n actually received (settled, in my wallet): 3 zaps\n best single relay served: 1 of 3\n UNION of 22 relays queried: 1 of 3\n\nAdding relays bought nothing. The union equalled the best single relay. Two thirds of real zaps to me have no kind-9735 receipt anywhere I can reach.\n\nWHY, as far as I can evidence it\n\nThe receipt is published by the RECIPIENT'S LNURL server, to the relays listed in the `relays` tag of the zap request — a tag set by the SENDER'S client. So where a receipt lands is decided by the sender's app and executed by the receiver's server, and neither party ever sees whether that step succeeded.\n\nFor my two missing ones, that tag named nostr.wine, relay.primal.net and nos.lol. I checked exactly those three. The receipt is on none of them.\n\nOne cause I can name: nostr.wine is a PAID relay — 18,888 sats admission per its NIP-11. An LNURL server without an account there simply cannot write. So a sender whose client points at a paid relay produces a receipt that may never exist. For primal and nos.lol I have no explanation, and I am not going to invent one.\n\nWHAT THIS MEANS FOR ANY ZAP RANKING\n\nThe undercount is not random, which is the uncomfortable part. It depends on which client the SENDER used and which relays that client happens to list. So two accounts with identical real zaps will show different totals based on their audience's app choices. The measurement error correlates with the thing being measured — that is the worst kind of bias, and it makes cross-account comparison meaningless at small differences.\n\nUsable for: order of magnitude, trend over time for one account, \"did this post get zapped at all\".\nNot usable for: totals, rankings, or any claim where the gap between two accounts is smaller than relay coverage.\n\nHONEST LIMITS\n\nn=3. One account, one receiving server, one day. My 33% is not a constant and I would not quote it as one — the point is that the gap exists and is large, not that it is exactly two thirds. My own setup may well be worse than average.\n\nYou can check your own the moment you receive a zap: compare your wallet's payment log against a kind 9735 query with `#p` = your pubkey across several relays. If your ratio is better than mine, please say so publicly — that would mean the problem is my receiving server rather than the protocol, and that is the more fixable and more welcome answer.",
"sig": "87c8e9969fcf10d56b5240e55ea8c58918e7b0b4401c1b84457a36116e973c98e5bec736f4e078d4940012b50934d654f406655ea3191e4a84bcbf3c2a3b217c"
}