Smart Contracts - Which options do we have?

[JPJA]

@Lotsofalgos

Hard coded features should be the main focus. The project could gain traction quickly if the right features are available and simple to use. Counterparty’s simplicity should be its strength.

Good. I’ve heard others say the same, so this should likely be the focus.

@Lotsofalgos

I think a lottery would attract a lot of interest. The auction idea is interesting as well; instead of a limit order to sell a token maybe you could have the option to send an order to DEX that accepts the highest offer price submitted during some number of blocks.

Cool. What do you think of my lottery suggestion? Auction, too, is a very good idea. Tokens with very low trade volume would really benefit from this. Like if I own an ultra rare Pepe and I have no idea what it’s value is, I can put it out for auction. I guess this would be separate from the DEX, and the parameters could be as following:

• Asset to auction off
• Lot_size (amount of tokens to auction off (special case 0 would be the token issuance ownership))
• Currency (the asset to get in return, e.g. XCP or PEPECASH)
• Currency_amount (the minimum bid)
• Bit_increment (the required increase in bid)
• Wait (number of blocks to wait for higher bid)
• Expire (number of blocks the auction is active)
• Cancel_fee (if currency is BTC and payment is not made, charge this XCP fee)
• BTC_pay_deadline (if currency is BTC, allow this many blocks to make payment)

Ideally all these parameters should fit within an 80 byte op_return, which I think they will do.

@Lotsofalgos

Finally a lot could be done if a simple contract or application could receive and own BTC, XCP and other tokens

BTC is a special case. The protocol cannot escrow or send BTC. Therefore there must be some sort of logic; if you send X BTC to address Y before block Z then you get asset in return.