Salvo

Appearance

Hidden intents (commit-reveal) ​

Status: built for the crypto rail, testnet only; not on the card-hold rail

Salvo Pay, the crypto rail, does this: commitments on chain, tickets bound to one buyer, and a book shown only as store totals. Its escrow has been on Tempo's test network since 2026-10-10, and it is not reviewed. The card-hold rail still publishes its book (below).

The problem: a public book gets picked off ​

A listing says what it is worth: the store, the value, the price, the discount. If anyone can watch listings appear, a bot can see a valuable card hit the book and take it before a real shopper does. On a public blockchain it is worse, because anyone can see a buyer's transaction before it lands and race it.

This is different from the vault. The vault hides the card number. Commit-reveal hides the intent: that this card, at this price, is for sale at all.

The design ​

  1. SellerLists a card
  2. CommitOnly a fingerprint of the listing is published, not its terms
  3. MatchThe matcher sees the terms and picks the card for a shopper
  4. RevealThe terms are shown at execution, to the matched buyer only

The fingerprint is a hash of the terms plus a secret. Anyone can later check the revealed terms against it, so they cannot be changed after the fact.

Nobody watching the book can tell a valuable card from an ordinary one, so there is nothing to race. The terms stay checkable, because the reveal must match the fingerprint published at listing.

Where we are today ​

The offer book is public. GET /api/supply/offers lists every open card with its store, value, price, discount and last four digits, best discount first. That is exactly the book this design is meant to hide.

It matters little today, for two reasons:

  • Every listed card is recorded as the operator's own, so there is no seller on record to lose a card to a bot. A stranger can still type a card into the public sell screen; that hole is an open decision.
  • The register flow does not use the book. The shopper types an amount and we pick the cards.

It starts to matter when other people's cards are listed, and much more if listings move on chain for the fallback route.

The trade-off. A hidden book cannot be browsed card by card. The browse page would show what stores have supply, not each card's discount. The register flow already works that way.

On the crypto rail ​

This is how Salvo Pay hides its book. It is built, and its escrow is deployed on Tempo's test network (2026-10-10). It is not reviewed: on the testnet a listing is taken as the operator's own card.

  • Only a commitment goes on chain. The seller's list call records a hash of the terms, a random salt and the sealed card's hash. The listing id includes the seller's address, so nobody can copy the commitment and register it first.
  • A ticket names one buyer. The terms and the sealed card travel to a matched shopper only, with the quote. The ticket Lit signs names that shopper's address and phone key, so a bot watching the chain cannot use it. The sealed card is never on chain, so a bot cannot ask for its own ticket.
  • The book is store totals. GET /api/escrow/listings answers, per store, how many cards, their total value and the best discount. Never one card's terms or its seller. The card-hold rail's lists leave escrow listings out.