diff --git a/src/components/slides/ZapReceiptSlide.vue b/src/components/slides/ZapReceiptSlide.vue
new file mode 100644
index 0000000..1ef1fad
--- /dev/null
+++ b/src/components/slides/ZapReceiptSlide.vue
@@ -0,0 +1,72 @@
+
+
+
+ The event the provider publishes when your zap is paid:
+ Clients trust it only if p = who was zapped
+ description = who zapped (your signed 9734)
+ pubkey matches the
+ nostrPubkey the recipient’s provider advertised — that’s what stops fake zaps.
+
Their Lightning server publishes a signed zap receipt.
+Their Lightning provider signs a zap receipt.
- Once the invoice clears, the server signs a receipt proving payment and posts it to relays.
- Now the zap shows up publicly under the note — amount, sender, comment.
+ The provider has its own Nostr key. When the invoice clears it
+ signs a kind 9735 event — tagged with
+ who was zapped and embedding your signed request (which says who
+ zapped, how much, and any comment) — then posts it to the relays you named.
- Under the hood (NIP-57): your client attaches a signed
- zap request (kind 9734); the recipient’s server returns a
- zap receipt (kind 9735). The server must opt in via
- allowsNostr.
+ Under the hood (NIP-57): your signed
+ zap request (kind 9734) rides along with the LNURL-pay invoice; the
+ provider advertises allowsNostr + its
+ nostrPubkey, and clients only trust a
+ 9735 receipt signed by that key. (Next: its anatomy →)