This is a proposal I made for Counterparty. Can perhaps be implemented and tested on Dogeparty first?
Problem 1: Trust is currently needed when selling an asset for BTC.
Problem 2: Bundles and asset ownerships can not be traded on the DEX or dispenser.
Solution: Introduce a swap contract. Counterparty escrows the asset and no trust is necessary.
Background:
- On the protocol level the only trustless way of selling for BTC is with BTC_PAY on the DEX. Unfortunately this is only implemented on FreeWallet and not yet properly peer-reviewed. The DEX is also limited to a quantity of a single asset - bundles and asset ownership are not supported.
- The dispenser is very convenient but trust is needed. It also supports tokens only, not ownerships.
- Third party services, such as CoinDaddy and Scarce.City, can offer escrow but are inefficient and potentially a legal burden for the operators.
How a BTC-Swap would work:
- Buyer and seller negotiate off-chain, e.g. in a chat or through a service such as CoinDaddy or Scarce.City.
- Agreement is made off-chain and the seller broadcasts on-chain a message with the conditions for the swap.
- Counterparty escrows the asset.
- Buyer sends BTC to seller.
- Counterparty releases assets to buyer.
Technically a new transaction type should be introduced with the following parameters
- CNTRPRTY prefix (8 bytes)
- Message ID (2 bytes)
- BTC quantity (8 bytes)
- Block height deadline (8 bytes)
- Buyer address (21 bytes)
- Swap type (1 byte)
- Swap asset (8 bytes)
- Swap quantity (8 bytes)
Total 64 bytes (fits op_return)
Swap type 0:
- Entire address is sold (all balances and ownerships). An XCP anti-spam fee should be applied if more than N assets. ‘Swap asset’ and ‘Swap quantity’ parameters are omitted.
Swap type 1:
- Asset ownership is sold. Only one asset can be sold in one swap. ‘Swap quantity’ parameter is omitted.
Swap type 2:
- Token quantity is sold. The asset quantity must be specified.
As soon as a swap is registered and approved by Counterparty, any BTC send to the seller’s address is recorded. This is very similar to dispenser. But since the buyer’s address already is specified, it does not matter where the funds originate from. This adds flexibility and reduces the risk of user error. Counterparty should also let the incoming BTC accumulate so that potentially several BTC transactions can be made.
Once the cumulative BTC received is more or equal to the ‘BTC quantity’ specified, the asset is transferred to the ‘Buyer address’. However, if the BTC amount is not received by ‘Block height deadline’ the asset is returned to the seller.
I believe this is a fundamental building block missing in Counterparty. It should help facilitate risk-free trading, as well as eliminate the burden of third party escrow.