CIP Proposal - Decentralized Asset Sales

Development Counterparty
1

This thread is about a potential CIP that would allow for asset names to be bought and sold on a “decentralized marketplace”, much like how orders are matched on the “decentralized exchange”.

I think this CIP could dovetail nicely with CIP 3 (discussion), but neither are dependent on each other.

CIP 3 specifies that…

If the asset owner holds the entire supply and the asset is not locked, then allow the owner to reset the supply (e.g. set the supply at zero) and change the divisibility status.

This potential CIP would specify something like…

If the asset owner holds the entire supply and the asset is not locked, then allow the owner to create offers to sell their asset name.

The Counterparty protocol allows for the ownership of Counterparty assets to be transferred to any Bitcoin address. This CIP proposals aims to replicate that same functionality, but gear it towards selling Counterparty asset ownership.

Currently, to transfer an asset’s ownership, users broadcast txs that define the new owner’s Bitcoin address. (See: create_issuance.)

Read more about how it works here: Transfer ownership

Right now, the decentralized exchange matches orders and, as a result, credits and debits address balances. The idea is that a decentralized marketplace could match offers and, as a result, transfer ownership of asset names.

For example, rather than creating an order to GIVE 10 XCP in order to GET 1000 BXX… On this decentralized marketplace, you would create an offer to GIVE BXX OWNERSHIP to get 10 XCP.

When offers are matched:

  • The address balances would be debited/credited, like how create_order works.
  • And the asset’s ownership would be updated, like how create_issuance works.

We have the experience of doing the two things separately. If people like the idea, I think we can create a new message type, like “offer”, and we can do it well.

I also think this potential CIP would pair nicely with my Three Letter Asset Names proposal. Please read that too. And don’t forget CIP 3! I think together they represent a very robust improvement, but even individually they each add a lot to Counterparty’s value proposition and potential for network effects.

1 Like
2

+1

Technically it can be made a simple as

  • If sell quantity is 0, put ownership for sale on DEX
  • Some api update needed
  • Wallet GUIs
3

Sure, that’s a possible way. I prefer separate messages (offer vs order) and concepts (marketplace vs exchange), to avoid confusion. For example, when cancelling an order, you do not specify a quantity.

4

Good point. Do you think this upgrade (offer) can be bundled with other kinds of swaps?

  • I’d like to offer a bundle of pepe cards.
  • Would be good to swap BTC-XCP or BTC-PEPECASH. If I find trading partner in chat, I can make offer like I sell 250 XCP to Alice for 0.5 BTC (protocol escrows my 250 XCP) and now Alice has X blocks to make the BTC-pay. If she’s later than X blocks, an increasing penalty occurs until Y blocks hard deadline.
5

That would be outside the scope of this CIP proposal, but the traditional way to “bundle”, in the context of an exchange, is through trading a fund. And that is well within the existing capabilities of the DEX.

6

Love this idea! Care to write a formal cip? I would remove the need of complete ownership of tokens, I could sell i.e. rarepepeprty ownership to sell the whole business without it affecting the token holders (not like we’re gonna do soon, just an idea).

1 Like
7

Yes, I agree that ownership of all the tokens isn’t essential.

8

I like this idea @droplister.

It looks sound to me. I don’t see any technical limitations here.

The next step is to write up a formal CIP.

Brainstorming Idea: Do you want to use the DEX for this with separate offer and fulfillment messages? Or would you rather do an atomic swap message signed by both parties? An example of an atomic swap message would be “Alice sends Bob 25 XCP and Bob transfers ownership of BOBSPIZZA to Alice”.

With atomic swaps, orders would be matched by a 3rd party service and then broadcast to the blockchain after both parties sign the message.

I suggest this because every blockchain message costs so much these days…

9

I do not want to use the DEX. I would like this to be considered a separate concept. New territory for Counterparty. I’d like to think of this as a marketplace or an aftermarket rather than an exchange. I don’t have a snappy nickname for it, but we’ll get there.

I think it’s important that our analogies and naming conventions match expectations. The literal ownership of IBM is not for sale on NASDAQ, for example. That doesn’t happen on exchanges.

I’ve seen this kind of muddling become common in Counterparty and I dislike it. Above, Jurgen proposes what amounts to a permissioned OTC trade on the DEX. I’ve seen this proposed elsewhere too. I consider this a tangent to this CIP proposal, but I’ll try to tie it all together.

If you find someone who is willing to buy at a certain price, you can just sell to them OTC. If you want to minimize risk, you can use contracts, escrow, or multisig escrow with a trusted third party.

Or, more simply, you can just create an order matching the agreed upon quantity and price on the DEX. I think that if you’re worried about someone else “taking” the deal, you shouldn’t use a decentralized exchange. Don’t ask the cutting-edge decentralized exchange to neuter itself.

It makes no sense for a decentralized exchange – any exchange – to have permissioned buy/sell orders. That’s not how exchanges work. You can sell to the highest bidder or buy from the lowest seller on the DEX --or-- you can do an OTC trade with the people you prefer.

The intention of my design is to mirror the atomicity of the DEX, the ability to trustlessly, permissionlessly, buy and sell, but do it for asset ownership. And treat it conceptually as its own thing, whether it’s the DAF or the DMA or the DAS.

Right now, I can privately transfer asset ownership, but I cannot simply list it for a price, like I can with the issuance. In a way, it’s a nice mirroring/balancing. You would have an offers and an offer_matches, and an offer_expirations table, just like with orders.

Re: Third Party
If someone wanted to match offers off-chain and broadcast them when matched, they could do that. We can do that right now for orders, but no one does. There is no reason to alter the design of this proposal to be geared towards third parties.

The goal is to have no counterparty risk, not to design for counterparty risk.

Re: BTC Fees
In the end, Bitcoin’s fees are Bitcoin’s fees. I can’t change that.

2 Likes
10

I would like to:

  • List an asset for sale and have the offer never expire (if not sold)
  • Optional bundling of asset ownership offer with tokens
    • Eg I own asset with 100 tokens. I want to sell all my tokens too.
  • Allow price discovery through auction (optional parameters)
    • E.g. I list asset for sale at 2 XCP. When a buyer matches my offer, his 2 XCP are escrowed with condition that any higher bid (step 0.5 XCP) within the next one day gets the asset.
    • But of course, with the new higher bid the process repeats
    • These are all parameters chosen by the seller. Seller can disable this if he wants (ie buy now).

Why these suggestions add value:

  • I have many assets for sale. I want to place them all for sale now and dont worry about paying BTC fees again after offer expire, to adjust price, etc
    • Even if one asset = one btc transaction, I don’t mind. I’ll pay a low fee and wait for txs to go through (Sunday night, or whenever the network is less clogged)
  • Assets for sale inside protocol are much easier to buy than going through a 3rd party, finding owner in chat etc. Imagine someone wants ZEBRA, type it in Counterwallet, and today all they see is that it’s taken. After we get asset listing in protocol, the user may not even need to know it’s 2nd hand. GUI just tells it for sale at 3 XCP … buy now!
  • Less asset names get lost. Even if the owner loses his keys, forgets about Counterparty, etc, the name remain for sale.
  • With auction I will put very low starting price. Some names I’m even willing to sell below 0.5 XCP … but since I’m clueless about the market price, I don’t want a shark to snap up underpriced names immediately. Auction adds price discovery … which is fair … and optional anyway if the seller does not want it.
1 Like
11

Some more notes:

  • I like droplister’s suggestion to make this a separate concept from DEX.
  • deweller; with a swap … can I create an order today, have some 3rd party store it and eventually a buyer signs the swap? The 3rd party confirms that what I placed for sale still is available and then broadcasts the BTC tx?
  • Why not make this concept (OTC, Swap, DAS, you name it) be more general? What if offer can be an asset ownership, a quantity of tokens, or a bundle of several asset names and token quantities?
  • Great if some BTCpay can be built in? Either make offer for a specific address to make BTCpay, or do same as with DEX where potential buyer first make a matching order and then can do BTCpay? BTCpay can have soft limit (e.g. 9 blocks set by seller) and a hard limit (e.g. 60 blocks) which incurs a penalty since buyer is late.
12

Concept ACK, got a CIP writeup / implementation?

13

Dan, write a CIP about this one… seems worthwhile.

You could establish the interaction like this:

  • Party A Owner of ASSET

  • Party B Buyer

  • Party A emits a new asset transfer sale order specifying: Price, Receivable Asset, Validity. This could be a broadcast, no need for another message, i.e. ASSET_ID_HEX + RECEIVABLE_ASSET_ID_HEX + QUANTITY_HEX + VALIDITY_HEX (FITS! 52 bytes max broadcast size). If either asset id is invalid the broadcast is silently treated as just another broadcast

  • Party B send the corresponding amount of Receivable Asset before the validity period, with a special memo: TRNSF:ASSET_ID_HEX (the literal “TRNSF:” value concatenated with the bought asset id in hexadecimal, also fits on the memo field).

  • If the asset can be bought, the send is marked as valid, asset ownership transferred and receivable asset credited to seller, debited to buyer.

  • If the asset can’t be bought (because the asset is no longer property of the seller) the message is marked as “invalid: asset not owned by address” (so the credit/debit doesn’t happens).

I guess this would simplify a LOT selling assets.