Token Exchange Protocol for UTXO-based Overlay Networks
Swapping a token for payment with a stranger requires one of you to go first, which neither party wants to do. This describes an exchange between two parties where neither has to trust the other to complete their side.
Summary
- Why
- Two parties who do not trust each other need a way to swap two different tokenized assets without a middleman holding funds and without either side being able to cheat by taking both assets.
- What
- BRC-79 is a peer-to-peer protocol for two parties to exchange tokens directly on a UTXO-based (Unspent Transaction Output) overlay network, using signature types that make the trade atomic.
- How
- One party locks their asset into an offer output on the overlay network, the other party builds and partially signs a transaction with SIGHASH_SINGLE claiming that asset while paying the offer maker, and the offer maker completes the trade by signing with SIGHASH_ALL and broadcasting.
What this lets you do
- Post a token offer visible on an overlay network
- Cancel an offer by spending it back before anyone accepts
- Accept an offer with a partially signed transaction
- Verify a counterparty's UTXOs before settling
- Finalize a trade with a single broadcast that pays both sides
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-79 accurately, including what it depends on.
The specification
Abstract
We propose a peer-to-peer token exchange protocol under which two parties can securely exchange digital tokens (assets) within Bitcoin SV's BRC-22 UTXO-based Overlay Networks.
Motivation
The motivation behind this protocol is the need for an efficient and secure mechanism to exchange different types of tokenized assets on top of overlay networks between two parties in the BSV ecosystem.
Specification
The protocol is initiated when two parties, Alice and Bob, desire to conduct an asset exchange. It assumes that both parties are online. We specify this protocol conceptually, by example:
-
Offer Initiation: Alice wants to sell 5 apples for 3 USD. She creates a new transaction moving her 5 apples into a new output. This output includes her exchange request, peer-to-peer contact information (such as BRC-33), and the asset ID for the asset she would like to exchange, reflected in a new transaction on the overlay network.
-
Revocation by the Initiator: If Alice decides to cancel her proposition, she can spend the offer output and move her apples back, retracting the offer.
-
Offer Acceptance: Bob is looking to purchase 5 apples for his 3 USD. He sees Alice's offer, verifying her offered UTXO(s) are registered on the overlay. Bob creates a new transaction, conditionally signing his USD over to Alice using
SIGHASH_SINGLE. He ensures the signature is only valid over all the inputs from both Alice and Bob. The single output which he signs pays himself the 5 apples from Alice's inputs. -
Offer Presentation: Bob contacts Alice, identifies himself and shares the transaction and signature with her.
-
Verification: Alice verifies the information and conducts due diligence to confirm Bob's outpoints on the overlay network. She verifies the signature and the validity of the transaction. If she decides not to proceed, she can simply do nothing or send Bob a rejection message.
-
Transaction Settlement: Alice responds by signing her inputs with a
SIGHASH_ALLsignature, spending her inputs, and adding an output that pays her Bob's 3 USD. She adds her signature to the transaction, and broadcasts it to Bob and the overlay network. Once her transaction reaches the overlay network, Alice now possesses Bob's 3 USD and Bob is the owner of Alice's 5 apples.
Implementation
This Token Exchange Protocol can be implemented on any UTXO-based overlay network adhering to BRC-59, BRC-45, BRC-22 and BRC-24. This protocol has security built-in, stipulating both SIGHASH type usage and broadcasting and topical membership verification methods.
Future work
In general, overlay network recovery mechanisms for uncooperative participant handling (non-registration or improper broadcast of transactions) need to be defined as part of future specifications. Further tooling and guidance for developers would expand adoption.