Idea: Token Auctions

Development Counterparty
1

The DEX is one of the most popular features of Counterparty. However, there are situations where it does not work well (or not at all). Token auctions will address several of these cases, such as:

  • Asset is rarely traded. Therefore the seller does not know where to place ask price.
  • Seller owns 100 GAMECRYSTALS, exactly what’s needed to level up. Seller is only interested in selling all or nothing.
  • A card designer wants to sell a card bundle
  • Asset issuer wants to sell the issuance right (also called asset ownership)
  • Tokens are for sale against BTC but seller requires XCP compensation in case they buyer does not fulfill his BTCpay promise

An auction will require these parameters

  • lot_assets - one or several assets for sale
  • lot_quants - corresponding quantities
  • bid_asset - buyer must pay with this asset
  • bid_min - lowest allowed price
  • bid_incr - new bid must be at least this much higher than previous
  • deadline - if no bids, expire the auction after this # of blocks
  • hammer_wait - after valid bid, wait this many blocks until hammer falls (auction ends)
  • btcpay_wait - if BTC involved, wait for BTCpay this many blocks after auction ends
  • xcp_deposit - if fail to make BTCpay on time, the counterpart will receive this XCP compensation

Example auctions

  • Alice sells her entire collection of Pepe cards. She puts them all in one auction lot at minimum price 100 XCP. Bob makes a valid 100 XCP bid, and the system waits 60 blocks (~10 hours) for a higher bid. After another 45 blocks Charlie places a new bid, one increment higher, at 110 XCP. Another 60 blocks passes and no new bids are recorded. Alice’s Pepe lot is transferred to Charlie for 110 XCP.

  • Alice has 10,000 XCP for sale. She’s chatting with a potential buyer and places the XCP for sale against BTC. To keep the exchange rate risk (fluctuating price risk) at a minimum she sets the deadline at 6 blocks and hammer_wait at 0 blocks (i.e. the first minimum bid gets it now). The btcpay_wait she sets a bit higher, otherwise the buyer would be at risk of not making it on time, so it is at 20 blocks. In case the XCP price drops in the meanwhile and they buyer thus have the option of dropping out, she demands a 200 XCP deposit.

  • Alice owns the asset name Charlie. She has no idea what it’s worth, nor does she have any plan of ever using it herself. She puts if for sale at 1 XCP with a very high deadline (virtually forever). The hammer_wait is 432 (~3 days) to give more people a chance to bid up the price. It turns out that Charlie makes a bid very quickly. After 3 days have passed, no other bid is recorded, and Charlie gets the Charlie name for 1 XCP.

3 Likes
2

I love auctions, but it’s very difficult to do them on a blockchain because all bid information is totally transparent.

When you participate in an auction on Ebay, you place your maximum bid but don’t neccesarily have to pay that, unless someone else bids up the price to just under your maximum bid. On Ebay, nobody can see your maximum bid, so someone bidding against you has to take a risk that they will become the maximum bid in order to try and bid you up to your maximum price.

Back in 2014 we built a token auctioneer, it was entirely built around on-chain transactions, basically we set up an “Auction Address” which people would place bids with by sending their maximum bid. The system would bid the minimum to make them the high bid, but then people would know exactly how much to bid by looking at the blockchain and either using that information to maximize the price the bidder was going to pay, or to outbid them by a single interval.

On Ebay, you don’t get charged per bid you make or action you take. In your proposed system, you would get charged every time you make a change and the bidding settlement periods you are proposing are perfectly set to be trolled indefinitely by making tiny bid increases days into the waiting period but before it actually ends. Every time I do this, I force the legitimate bidder who wants the thing to a) wait longer, b) pay another fee, c) pay more.

To make that information not matter, you make it so placing a bid is not auto-bidding based on price, but that someone sends their entire bid. The problem here is that you have to make a lot more bids in a contentious auction and since the auction has no fixed end time this can go on indefinitely.

After our experiment with the auctioneer, which we eventually shut because the perfect-knowledge situation was creating asymetric results for sophisticated bidders vs. normies, we came up with a better plan for creating a token auctioneer. It neccesarily can’t be done entirely on the blockchain if you don’t want everybody knowing what everyone else is bidding.

So to summarize, I like the idea but I think doing it entirely on-chain will be a huge non-starter because a) costs, b) time a user needs to be engaged with an auction which has more than one bidder, c) non-intuitive, asymetric advantage for sophisticated users over normal users.

4

Sure, Ebay’s secret max bid model cannot work on a blockchain. My suggestion is in line with traditional auctions.

Why a lot more bids and what’s so contentious about it? if it goes on indefinitely, great for the seller!

The seller can set whichever ‘minimum bid’, ‘bid increment’ and ‘wait until hammer falls’ as she pleases. Sellers will soon learn the optimal parameters.

If Alice puts her Pepe collection for sale at 100 XCP with an increment of 10 XCP, she’d be happy to see the price increase from 100 to 110 to 120 to 130 etc, right?

If she were to set the increment very low, like at 1 XCP, sure, then it could get irritating. Bidders wouldn’t be happy wasting all those transaction fees and Alice wouldn’t like the wait. But the interests of seller and bidders are aligned here, so I don;t see the problem (beyond some seller choosing stupid parameters once before learning).

From the bidder’s point of view there’s always the risk of not winning, i.e. losing a transaction fee. This is not preventing 100s of orders being placed on the DEX every day; around half of them limit orders that may never get filled. Why would this be any more of a non-starter for auctions?

a) The DEX too is very costly since every order (and cancel) requires a btc fx fee, yet it is highly popular.
b) If this is a problem the seller should optimize parameters to attract bidders
c) Any more than in any other market?

As a final note; I agree we must careful design the auction with the advantages and limitations of Bitcoin in mind.

1 Like
5

Fast forward 4 years. 2021 now.

Should probably simplify it?

  • Only allow one asset for sale, not multiple
  • Buyer must pay with BTC, i.e. remove bid_asset
  • btcpay_wait can be a hardcoded magic number as in the original DEX BTCpay

The success of the dispenser shows the demand for selling tokens for BTC. An auction functionality would be even better for all our rare collectibles.

AND it would remove the need for centralized auction houses - perfectly in line with Bitcoin & Counterparty’s peer to peer philosphy.

1 Like
6

I think it is a bit early to try to implement auctions on Counterparty… but another platform will be forthcoming shortly which will be the PERFECT place to implement and test this feature… and if it works successfully, getting the feature ported up to Counterparty would be pretty easy.

I think that a bunch of these proposed features that have been waiting to be implemented/tested on CP are going to work well on this new platform… Platform will be revealed in a few weeks and then it will all make more sense :slight_smile:

1 Like
7

Made an updated proposal - CIP - Auction Contract