Threat model

What we store, what could leak, and what you trust us with.

Privacy that only looks right is worse than none, because people rely on it. Here is the whole picture.

Everything the server ever stores

Event details
Title, time, place, capacity, deposit. All but capacity and deposit are wiped on purge, so an event id left in an attendee's wallet no longer leads anywhere.
Ticket hash
SHA-256 of a random secret. Reveals nothing about the person.
Refund address
A one-time shielded address the attendee chose. Unlinkable to their other addresses.
Checked in
A yes/no per ticket. No time, so arrivals can't be matched against cameras. It's never published while the event runs; every ticket's outcome appears at once when the event is settled.
Seat
A random number, so it says nothing about the order people paid in.
Deposit notes
Transaction id, amount, block height. The sender is never visible, even to the wallet.
Payouts
Each refund, return and sweep: its recipients' refund addresses, amounts and memo, and its transaction id. Deleted on purge.
Link hashes
SHA-256 hashes of the manage and door links, so the server can check them without storing them.
Reused-address digests
Keyed hashes of refund addresses, only to refuse reuse. Never the address itself. Forgotten after one to two years.
The event's wallet account
Its own seed (encrypted at rest) and the deposits' memos. Purging deletes the account and the seed, so the memos can't be decrypted again, even from the chain.

After an organiser purges a settled event, only aggregate counts remain: how many RSVPed, came, were refunded and were forfeited.

Known leaks and how each is closed

Reusing a refund address

The same address at two events would link one person's attendance across both.

Mitigation · The server refuses any address it has seen before and returns the deposit.

Network metadata

Loading a page reveals an IP address to the web host and the API host, and their providers may log it.

Mitigation · The API itself keeps no access logs. Confirmation checks download every ticket hash, so no request points at one ticket, and your ticket list never asks about all your events at once. For high-risk groups, open the pages over Tor.

The wallet's sync server

To read a deposit's memo, the server's wallet fetches that transaction from a lightwalletd server. Its operator would learn which transactions are RSVPs, and could match them to attendees' own wallets broadcasting through the same server.

Mitigation · The wallet reaches lightwalletd through Tor, with a fresh circuit for every transaction it fetches. Operators can also run their own lightwalletd.

What stays in your wallet

Memos stay in a wallet's history for good, and anyone who later sees the wallet can read them.

Mitigation · Refunds and returns carry a fixed memo that never names the event, and purging wipes the event's name, so the event id in your deposit memo leads nowhere.

Odd amounts

A unique deposit amount could stand out.

Mitigation · Every RSVP must pay exactly the same deposit, so inside the shielded pool they all look alike. Anything else is returned. Organisers should pick a round amount.

Transparent funds

Paying from a transparent (t-address) balance shows the payer's address and the exact deposit amount on the public chain, which can tie them to the event.

Mitigation · Event addresses are Orchard-only and refunds are sent with the wallet's FullPrivacy policy. Attendees should pay from a shielded balance.

The ticket itself

Whoever holds the QR code can use it once.

Mitigation · Treat it like a physical ticket. It is stored only on the attendee's device, and the saved image doesn't name the event. Remove tickets for past events from your ticket list.

What you are trusting

  • The server's wallet holds deposits until the event is settled. A dishonest operator could keep them, so deposits should stay small (the price of a coffee).
  • The organiser's links are bearer secrets. Anyone with the manage link can settle or purge the event.
  • The door device sees ticket hashes, seats and the event's check-in count, and keeps them to work offline until the event is settled. It never sees refund addresses.
  • The organiser's dashboard shows each ticket's hash and whether it was checked in, but only a shortened refund address.
  • Unlisted can't hide that an event exists, or protect against someone photographing the room.
Home
--:--
Chain: …