how 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.