On 28 July 2026 at 14:15 UTC, in mainnet block 19,978, one unit of
COMPUTE.V26C2M — a tokenised option on TensorCash network difficulty — moved from one
person to another, and 0.90000000 TSC moved the other way. Both legs happened in
the same transaction. Neither side ever held the other’s money.
There was no exchange account. No deposit, no withdrawal, no order book operator, no escrow agent, no multisig arbiter, no “trusted” third party of any kind. Two people ran the TensorCash desktop wallet, found each other over an encrypted peer-to-peer channel, agreed a price, and pressed a button. The chain did the rest.
View the transaction on the explorer →
1e923ee8c490081e2f63dea34b4c9e8d81189b30db806652960a9852fd8d05ca
This is a technical demonstration, not an offer or a solicitation. Nothing here is an invitation to buy, sell or subscribe to any instrument, nor investment, legal, tax or financial advice. It documents how a piece of software works, during a technical demonstration between two consenting operators. Screenshots have been redacted: wallet names, public keys and the offer identifier are replaced with placeholders.
What changed hands
COMPUTE.V26C2M is one of the two option series we
wrote about last week — a call option on the
COMPUTE Index, which is simply the network’s difficulty read as AI-inference
throughput. It is fully collateralized: each of the 100 units is backed by 1 TSC sitting
in an on-chain vault, and at fixing height 28,416 the chain itself splits that vault
between holder and writer according to a published formula. No oracle, no issuer to
chase, no counterparty to trust at maturity.
So it is an asset with a real, chain-enforced payoff. Which raises the obvious next question: can you actually sell one to somebody?
Until this week the honest answer was “yes, if you both trust an exchange, or one of you goes first and hopes.” Now the answer is: yes, directly, with neither.
How the two parties agreed
1. The seller writes an offer
In the wallet’s Trading → Market tab, the seller opens the Spot builder and states
the terms in plain language: send 1.00 COMPUTE.V26C2M, receive 0.90000000 TSC. The
wallet turns that into a signed term sheet and hands back a share dialog.
Those four buttons are the whole distribution model, and they matter:
- Publish with Proof — post the offer publicly, and attach cryptographic evidence that you actually hold what you are promising to deliver.
- Publish to Market — post it publicly without that evidence.
- Export Manually — don’t publish anything. Save the offer to a file or the clipboard and send it to one named counterparty however you like. A genuinely private OTC ticket.
- Decide Later — keep it local.
The seller chose Publish with Proof.
2. The offer goes out over a board, not through a venue
“Publishing” means signing the offer and posting it to a bulletin board carried over
Nostr relays — the Relays: 1/1 indicator in the status bar below.
A relay is a noticeboard, not a venue. It stores and forwards signed notices. It runs no matching engine, holds no balances, takes no custody, and cannot halt trading, reorder your quote, front-run you or lose your coins — because at no point does anything but your own wallet hold your keys or your assets. Everything binding happens directly between the two wallets.
Buyers running the same wallet see the offer appear in their market table:
3. “Funds Verified” — the green tick
Look at the Funds Verified column. That tick is the Publish with Proof option paying off.
Attached to the offer are BIP-322 signatures: the seller signs a challenge message
with the private keys controlling the specific coins holding the
COMPUTE.V26C2M units. Any wallet that receives the offer re-checks those signatures
against the live chain state — the outputs exist, they are unspent, they carry the asset,
and whoever wrote the offer can spend them.
It is the difference between “I have the goods” and “here, check for yourself.” Nobody is asked to take the seller’s word, and no reputation system, rating or deposit is involved.
The same works in reverse: the buyer’s trade request carries proof of the TSC side.
4. The buyer requests the trade
The buyer clicks through, and a request lands on the seller’s screen, again with its own verified-funds tick. Requests queue here until the maker acts on them; the maker can Finalize or Reject each one.
The seller pressed Finalize. Everything after that is automatic, and it is where the interesting cryptography lives.
The hard problem: who goes first?
Strip away the interface and a trade is two payments in opposite directions. If they are two separate transactions, somebody has to send first — and that person is exposed. The other side can simply not pay.
The industry’s answers have all been variations on add a third party: an exchange that holds both sides, an escrow agent, a bonded arbiter, a bridge. Each one is a new place your money can be frozen, stolen, subpoenaed or lost.
TensorCash’s answer is different: make both payments the same payment — then give two strangers a way to sign it together in which neither has to go first.
What a cosign adaptor actually is
Start with what a normal signature does. When you sign a transaction you produce a number that only your private key could produce, and anyone can check it. It is a lock that either opens or doesn’t.
An adaptor signature — sometimes called a scriptless-script or “signature encryption” — is a lock with one piece deliberately left out.
Pick a secret number t. From it derive a public point T = t·G on the elliptic curve.
T can be shared freely; t cannot be worked backwards from it. Now, instead of a
finished signature, you produce an adaptor signature that is bound to T. It has three
properties that do all the work:
- It is verifiable. Your counterparty can check, right now, that it is a correct
adaptor signature by your key, on this exact transaction, locked to this exact
T. They know it is real. - It is useless on its own. It will not spend anything. The chain rejects it. It is
a signature with a hole in it exactly the size of
t. - It completes instantly, given
t. Whoever learnstcan turn the adaptor signature into a valid, ordinary Schnorr signature by simple arithmetic. And symmetrically: anyone who sees the completed signature next to the adaptor one can subtract them and recovert.
That third property is what makes adaptors a building block rather than a curiosity: a signature can be published in a form that is checkable now and spendable later, and the act of spending leaks a secret that other constructions can be chained to. Here, the wallets use the adaptor layer for what it gives them today — a way for two strangers to sign the same transaction incrementally, verifying every step, with nothing usable changing hands until the last one.
Putting it to work
Here is what the two wallets actually did when the seller pressed Finalize. The wallet log numbers them phases 0 to 4; the whole run took about two seconds.
Phase 0 — one transaction, built by both. The wallets don’t each build a payment.
They build a single transaction, cooperatively. The seller’s wallet drafts its own leg
— the output delivering the COMPUTE.V26C2M unit to the buyer’s address — and sends that
draft across. The buyer’s wallet augments it with its own coins and the output paying
0.9 TSC back to the seller, then sends it back. Each side contributes only its own leg,
which matters: only the wallet actually holding an asset knows how to construct a valid
spend of it.
The seller’s wallet then checks the returned draft rather than trusting it. It confirms every one of its own inputs is still present and unaltered, and that the merged transaction hashes to the value both sides expect, before adopting the buyer’s version.
At this point the transaction is complete, correct, and completely unsigned. Both parties can read every byte of it. Neither can broadcast it.
Phase 1 — prove who you are. Each side signs a challenge with the key controlling the address it is about to be paid at — BIP-322 again. This closes the gap between “somebody is talking to me on this channel” and “the party being paid is the party I negotiated with.”
Phase 2 — nonces. Schnorr signing needs a fresh random nonce for every input, and in a multi-party session those nonces must be fixed and exchanged before any signature is seen — otherwise whoever chooses their nonce last can bias the outcome. Both wallets generate theirs, publish the public halves, and merge in the other side’s.
Phase 3 — adaptor partials. Each wallet now produces adaptor signatures over its own inputs, bound to its session adaptor point, and sends them across. Each side checks that the other’s are well-formed against the exact transaction on the table. Both now know the transaction is fully covered — and both know it is still inert. Nothing here can be broadcast, and nothing either party has received lets them take anything.
Phase 4 — completion. The adaptor secrets are applied, the completed signatures are exchanged and merged, the few remaining ordinary inputs are signed, and the transaction goes to the network. Ten minutes later it was in block 19,978.
Where the safety actually comes from
Worth being precise about, because the distinction matters.
The atomicity is structural. There is one transaction. The buyer’s TSC and the seller’s option move inside the same object, validated by the same rules, into the same block. There is no ordering, no “who goes first”, and no window in which one leg has settled and the other has not — not because the parties behaved well, but because the chain has no way to accept half a transaction.
The ceremony is what lets strangers get there. Every step is verified rather than trusted: the merged draft is checked input by input, identities are attested with BIP-322, nonces are committed before any signature is seen, and every adaptor signature is validated against the exact transaction it claims to cover. At no point does either wallet hand the other something it can use on its own.
One protection was available and was not used in this run. The wallet also implements
a lock-step reveal: before releasing final signatures, each side commits to a hash of
the signature it is about to publish. Its job is to stop one party seeing the
counterparty’s completed signature while withholding their own — which would leave them
holding a fully valid transaction they could broadcast, or sit on, depending on which way
the market moved over the next few minutes. That is a free option, obtained for
nothing. Both wallets negotiated this trade with reveal_lockstep: false, and the
ceremony log records the bypass explicitly.
That is a fair-exchange refinement, not a custody hole. Neither side could have stolen anything, and neither side could have produced a one-legged settlement; the worst outcome reachable was a stall in which both parties keep exactly what they started with. Turning it on by default in the automated path is the obvious next step — and we would rather say so than let a tidy diagram imply it already happened.
The channel the two wallets talked over
All of that message-passing needs somewhere to happen, and it must not be a place where an eavesdropper can substitute themselves for one of the parties.
The wallets establish a cosign session. A SPAKE2 password-authenticated key
exchange runs first, and the secret it derives keys a Noise channel
(NNpsk0, X25519 / ChaCha20-Poly1305 / BLAKE2b). SPAKE2’s job is to make a
machine-in-the-middle impossible even though the shared secret is short and
human-typeable, and the handshake ends by showing both users the same short
authentication string — five words that must match on both screens before anyone
proceeds.
The transport underneath is a plain WebSocket rendezvous relay, which is deliberately uninteresting: it is a mailbox with a room number, and it sees only ciphertext. Every PSBT, nonce and signature in the ceremony above crossed it end-to-end encrypted.
What the chain saw
One transaction. Three inputs, five outputs, 487 vB, a fee of 2,705 sats.
| Leg | What it is |
|---|---|
1 × COMPUTE.V26C2M | delivered to the buyer |
1 × COMPUTE.V26C2M | asset change — the seller’s remaining unit from the same coin |
| 0.90000000 TSC | paid to the seller |
| 2 further outputs | native TSC change, one back to each side |
Confirmed in block 19,978, 9f0e2f53…c56d873a, at 14:15:40 UTC.
Notice what is not in that list: no escrow output, no timelocked refund branch, no hash-preimage, no multisig, no second transaction, no on-chain trace of the negotiation at all. To the network this looks like an ordinary Taproot spend, because that is exactly what it is. All the cleverness lived in how the signatures were made, and none of it costs block space. That is what “scriptless” means, and it is why this approach is cheap and private as well as safe.
Why this is a bigger deal than one small trade
TensorCash already lets you tokenise things that are hard to tokenise anywhere else: options on the network’s own difficulty, contracts-for-difference settled by consensus, repos, forwards. Those instruments are only as useful as your ability to get in and out of them.
This transaction closes that loop. The same wallet that mines, that holds your keys and that writes the contracts can now also trade them, peer-to-peer, with settlement finality and no settlement risk — and the machinery is generic. Spot was the first one to go end-to-end on mainnet; the Market tab already carries Repo, Forward, Option and Difficulty alongside it, and they share the same adaptor ceremony underneath.
An asset you cannot sell is a certificate. An asset you can hand to a stranger, safely, without asking anyone’s permission, is a market.
That market opened at 14:15 UTC on 28 July 2026, at a price of 0.9.
Technical demonstration only. Not an offer, solicitation, or recommendation to buy or sell any instrument, and not investment, legal, tax or financial advice. Peer-to-peer trading carries risk, including total loss; you are responsible for your own keys, your own counterparties and your own regulatory position. Wallet names, public keys and offer identifiers in the screenshots have been redacted.
Don’t trust — verify. The transaction is on the explorer; run your own node and check it yourself.
Authored pseudonymously by Imosuke Takakuni.