Every gift card is a Tari on-ramp nobody is using yet
There is a shop near me that sells Airbnb gift cards next to the phone top-ups. Somebody bought one
for a trip that got cancelled, and now it sits in an inbox. They would take Tari for it. Somebody
else would hand over Tari for it. Neither of them has a way to make that trade that does not involve
one of them going first.
That is the whole problem, and it is not the chain and it is not the fees. It is the first move.
Whoever sends the code first has handed over the money. Whoever sends the Tari first has handed over
the money. Every platform that ever fixed this fixed it by standing in the middle, holding both
sides, taking a cut, and asking for photo ID. Fine, if that is the experience you want.
A code is harder than a coin
A voucher code is not a token. The moment it is visible, it is spent. You cannot escrow a secret by
publishing it, and you cannot put it on a public ledger without giving it to whoever reads the next
block. So the trade has to happen without the code ever being published, which rules out most of the
tricks we usually reach for.
WunschSwap does it anyway. The seller delivers the code encrypted to a key the buyer chose, so the
ciphertext sits on chain and is useless to everyone else. The buyer spends it at the voucher site,
into their own account. Then the last part, which is where the work went: the chain pays the seller
only once the voucher site’s own balance has moved by exactly the face value of the code.
We never ask the site for anything special. We watch it do what it already does, in three ordinary requests:
before what does this account hold
redeem here is the code
after what does this account hold now
The money is released when the numbers add up. Which is why the balance is the signal and a
“redeemed” flag is not: a balance can be read twice, by different people, and the readings have to
match byte for byte, while a one-shot flag has exactly one moment where it is true and a single
bribed witness could fake it.
The notary rides along, it does not move in
The next question people ask is the right one. If a committee is watching the voucher site, have we
not just replaced a company with a handful of strangers?
The site is not asked to do anything either. There is no proxy installed in front of it, no API it
has to expose, no certificate it has to hand over, and nothing it has to be told. It never learns
that we exist.
The reason is that the conversation is not held by one machine. When your phone talks to the voucher
site, part of that TLS session is computed on your phone and part of it is computed on the notary.
The notary’s half is not a proxy or a log scraper, it is an MPC engine, the same mpz machinery the
TLSNotary work is built on, which is what allows two separate machines to hold one TLS session
between them. Together they are what the site sees: one ordinary customer, on its ordinary TLS,
making one ordinary request. Neither half on its own ever holds the session keys, so neither half on
its own can invent a transcript. That is the trick, and it is why a site that has never heard of Tari
can be traded against anyway.
Afterwards your app decides what the notary gets to read. It reveals the request and the response,
and it hides the one part that matters, which is the code. What the notary receives for the hidden
part is a digest computed across it, so it can check that the code matches the commitment on chain
without ever being able to open it.
And it does not take your app’s word for the rest. Before it signs anything, the notary insists that
the name on the certificate is the one it expects, that the response carries the label it signs for,
that the revealed request is the phase it was asked for and on that phase’s own route, that the
hidden range really is the code and is covered by exactly one commitment, and that the account named
in the response is the account on the trade. If any of that is off, it refuses the session instead of
signing something weaker.
What you are trusting, and what you have stopped trusting
No operator holds your funds, because there is no operator. The other trader cannot walk off with
your side, because neither side can move first and come out whole.
What is left is a small committee that witnesses those three requests. The design makes that as thin
as it can be. The members are drawn at random for each trade out of a set of attestors who have money
bonded, a quorum has to agree on the same bytes, and an attestor who signs something false loses the
bond. Best of all, the attestor never gets the code. It co-computes the redemption while holding
zeros in the place where the code is, and signs a digest that matches the commitment on chain without
ever seeing the value. There is a real difference between a notary who could rob you and a notary who
cannot read what it is notarising.
Limiting trust is not the same as deleting it, and it would be silly to pretend otherwise. You still
trust that a randomly drawn bonded committee is not colluding, and that a balance is a real balance.
Everything else, the custody, the first move, the ID check, the platform’s cut, is gone.
The RetoSwap seat, for Tari
RetoSwap showed what this looks like for Monero: no KYC, no custodian, two people and a protocol.
Tari should have that seat filled, and it should be filled with the thing Tari is genuinely good at,
which is being usable by people who do not know and do not care what a rollup is. Tari Universe is a
single button. That is the standard everything else has to meet.
So the voucher swap is the right shape for it. What a normal person actually has lying around is not
a wallet balance they are itching to move. It is a gift card they are not going to use. A gift card
they already own is the least learning a new user can possibly do.
The half that grows without us
Which brings us to the part we are most excited about. The voucher side is not an integration, it is
a contract. Any site that sells a code and shows a balance can be connected by whoever wants to
connect it, and we do not have to be involved, or informed.
Three requests, a response shape written down byte for byte, and a reference implementation you can
run locally and diff against. That is the whole requirement for the code.
There is one thing a deployment does have to be told, and I would rather say it plainly than let you
discover it. Not every site writes “redeemed”. One site’s “already used” is another site’s “invalid
code”, and the gate has to know which strings mean a fresh code and which mean a spent one before it
can accept any proof about that site at all. So an exchange records, once per provider, the words it
will accept. That entry is a setting rather than an approval, it is the deployer’s own step on their
own deployment, and it does not involve us. Anyone who would rather not ask at all can deploy their
own exchange component and register their own providers, because that is permissionless too.
And yes, all of that includes the big centralised sites. An Airbnb gift card is a balance and a
redemption like any other. Somebody who wants to trade them can wire up a provider, and it works
while the site never knows we exist. No API keys, no partnership, no call with a product manager.
That is the universe we are building towards: a Tari where every voucher site with a balance is an
on-ramp, and adding one takes a weekend rather than a meeting.
Where it actually is, today
A Tari community deserves the honest version more than it deserves a pitch.
The on-chain side is real and tested, including the escrow, the gate, and the slashing for attestors
who misbehave, with adversarial tests that try to cheat it and then check that nothing moved. The
phone app creates its own wallet with nothing typed, carries its own Tor, and takes every step of a
trade it can take alone; two emulated phones have walked a trade to Final in two taps. The voucher
provider, the MPC-TLS witness that keeps the code away from the committee, and an installer for the
attestor half on a VPS all exist too. The voucher code is never revealed to any third party, the notaries witness the redemption using a fork of TLSNotary’s tlsn GitHub - tlsnotary/tlsn: Rust implementation of the TLSNotary protocol · GitHub .
That enables us to only reveal the necessary info to the notaries and no account details.
It is testnet, and it has not been audited. Most of the interesting work left is on the provider half,
because every new voucher site is a new set of wire conventions to get exactly right, and that is
where we would love company.
What we would ask of you
First of all, please try our current version using our mock provider at https://wunschswap.com with our android app and vote for us in the contest. September Contest Thread
If there is a voucher site you would actually use, write a provider for it and test it.
Once we are ready for mainnet run a notary.
The code is at Making sure you're not a bot!