rich1.0charliesurf wrotecharliesurf (npub15w…tpy0d)https://nostr.now/npub15wtwxm5k92v3mtppwvwaghdzaclajfjavhuc88q4s3effmyeruwqmtpy0dnjumphttps://nostr.nowhow does nostr track who zaps who? #asknostr
Nostr doesn’t track zaps at the protocol level.
Zaps are inferred by clients by correlating Lightning payments with Nostr events.
Here’s the exact flow,
1. Zap request (Nostr side)
User A clicks “zap” on User B’s note or profile.
User A’s client creates a zap request event:
kind 9734
Contains:
pubkey of zapper
pubkey of recipient
note ID (optional)
amount (msats)
comment (optional)
This event is signed and sent to relays.
2. Invoice generation (LNURL)
User B’s profile has an LNURL / Lightning address in metadata.
User A’s client calls that LNURL endpoint.
The endpoint returns a Lightning invoice that includes:
The zap request event encoded in the invoice description or metadata.
3. Payment (Lightning side)
User A pays the invoice.
Lightning itself is blind — it doesn’t know about Nostr.
No identity is revealed on Lightning.
4. Zap receipt (bridge back to Nostr)
After payment:
The LNURL server verifies payment.
It publishes a zap receipt event:
kind 9735
References:
the original zap request (9734)
the invoice / preimage
recipient pubkey
This receipt is sent to Nostr relays.
5. Client-side reconstruction (this is the key)
Clients infer “who zapped who” by:
Matching 9735 (receipt) → 9734 (request)
Verifying signatures
Checking pubkeys and note IDs
Summing amounts per pubkey
There is no global ledger.
Each client independently reconstructs zap history from events it sees.
Important implications:
Zaps are soft-consensus, not canonical.
Relays don’t enforce zap validity.
Different clients may show different zap counts.
Fake zap receipts are possible, but good clients verify:
-invoice hash
-preimage
-LNURL domain
-signature chain
Nostr = intent + attribution
Lightning = payment
Clients = accountants
you can create custom zap analytics, trust scores, weighted zaps, or verified-only modes without touching the protocol.