Ring-signature checkout

A buyer, a facilitator, and a proof that the facilitator is one the buyer already decided to trust — without revealing which one. This page is served from an nsite (Nostr blobs + a manifest event); there is no server behind it.

Try it — the two-actor view (one window, both panes)

Both actors, one take

Buyer on the left, facilitator on the right. This is the surface used in the recorded demo. Recommended for a first look.

Open the two-pane flow

Separate tabs

The same two pages as independent clients. Open both in this browser so they share an origin — the token hand-off rides a BroadcastChannel.

Buyer Facilitator

What to do, in order

Fill the basket: two pizzas, 27,900 sats.
Look at the set — you do not pick anyone. The list is who you admitted, not a menu.
Press “Open the order”. It now accepts claims from every member of your set.
On the facilitator pane, press “Prove & claim this order”. The first valid proof wins; the buyer's verdict card appears: a member of your trust set signed this order — identity not revealed, anonymity set = 4.
Try a second claim: switch the facilitator's identity and prove again → refused, this order is already claimed by another member.
Try the attack button: replay the same proof for a different order → refused, LSAG signature verification failed.
Continue to payment: a real invoice is issued by the mint, but only because the proof verified. No proof, no invoice.
Watch the paid leg run by itself: mint reports PAID, the buyer mints the ecash, the token crosses, the facilitator redeems, and the mint confirms the buyer's proofs are SPENT before the order is released to the kitchen.

Honest notes before you draw conclusions.

The mint in these links is testnut.cashu.space, a test mint that pays its own invoices — that is what makes a paid leg watchable without funds. Drop the ?mint= parameter and it uses the signet mint instead, where the order simply waits for a real payment. A test-mint result is not a real payment.
The trust set and the roster are demo fixtures. The facilitator keys are derived from a public constant; no real key is stored anywhere in this site.
The hand-off between the two actors uses BroadcastChannel, which is same-origin and same-browser. Two tabs on one machine: works. Phone + laptop: not yet — that needs a relay transport, which is not built.
A ring signature is a risk signal, not deterrence: "one of N" cannot attribute a bad order to a vendor. Prevention needs a bond or escrow, which is also not built.

Source: mcp-cashu-exchange/apps/worker/public (branch pr/trust-ring-paid-leg) — the nsite is a copy of those static pages, nothing else. Electrum-side code: felixfelix-bot/electrum, branch pr/trust-vendor-plugin.