I should add that Counterparty as of today has multiple hard coded smart contracts:
The asset system is a massive smart contract, highly popular and the cornerstone of CP
The DEX allows for trustless trading of assets, also highly popular
BtcPay is specially designed to trade XCP (or asset) against BTC on the DEX. Trustless but requires an additional transaction, i.e. slow. Not much used.
Dividends allow X tokens of an asset to be distributed proportionally to the holders of another asset. Used about once every other day. Using it requires a tiny XCP fee as spam protection.
Oracles can broadcast text and numerical values to settle bets. Not much used.
Bets between two parties can be matched such that an oracle decides the outcome at an agreed upon time. Not much used.
Require Memo On/Off (address rejects any incoming transaction unless a text memo is attached, under development, very useful for exchanges)
I’m open to the idea of a smart contract VM, but hard coded features may be the safest, most stable approach after all.
Maybe a roadmap where we aim to upgrade CP with new features every six months is the way forward?
Pooled Lottery (can send asset to a contract address, it at block X sends everything back to one lucky winner)
Booster Card Pack (random or fixed)
Asset-BTC Swap (Alice gives Bob X blocks to transfer BTC in return for asset; improvement over BtcPay)
Asset Ownership Auction
Subasset Marketplace (owner of alphabetic asset opens up subasset registration to anyone in exchange for a fee)
Subasset Namespace Limitations (owner of alpha asset irrevocably limits the subasset space not to allow upper case, lower case, number, special cars, and/or puts a max length)
I would forget about Turing Complete EVM development for now. Projects that need this functionality will naturally gravitate to Ethereum. It would be nice for Counterparty to have this functionality eventually but should not be the focus in the near term.
A simple Counterparty-specific VM would be great, as it would provide a unique benefit to using Counterparty. There are many developers who would like to develop simple decentralized applications but learning Solidity and the nuances of Ethereum are a hindrance. This is a big project though. Are there enough people and resources available to make this work in a reasonable amount of time? There will be no benefit if a few people volunteering their time make a buggy mediocre VM that no one uses. This option should be explored if a team of top notch developers could work on it full time. If the resources aren’t available it should be shelved for a later date.
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.
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.
An updated roadmap would be helpful and informative.
Finally a lot could be done if a simple contract or application could receive and own BTC, XCP and other tokens, enter orders on DEX, and distribute token assets according to certain criteria like a timed interval, block number, or a request from a specific address. This functionality would cover escrow agreements and collateral based lending, two very important functions with widespread use cases.
It would be great to see specific cparty evm with hardcoded features. In the end you can possibly address 90% of needs with a handful of well tested standard contracts.
Good. I’ve heard others say the same, so this should likely be the focus.
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.
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.
I like where this is going. So far, I like the hard coded features that Counterparty offers and/or can be added. Kind of like carefully vetted ‘smart-contracts’.
Having a lottery might attract some interest to Counterparty but it’s also a tricky subject. The way the CIP is laid out makes a lottery happen automatically as a function of the protocol. This could be taken to imply that Counterparty is sponsoring a lottery.
If users could use Counterparty functions to create their own lottery using the protocol I think this would be a good solution. A function could be made available similar to what is outlined in the CIP but require a user to initiate it and specify the details like number of participants, bet size, number of blocks, ect.