The DevShares chain that bytemaster mentioned is related to an idea that has been cooking in my head for some time now. The way I have been thinking about it is a bit different, though. I think it could function as a full DAC, within Bitshares. Basically, its purpose could be for funding and investing in new Dacs within the BTS SuperDac (e.g. BitAssets, VOTE, Play, etc) as well as investing in Dac Developers. This would have more leverage for the investor than simply investing in BTS, and in a way that has DEFLATIONARY effects to BTS if the venture or Developer fails. While this approach may not have as much 'firepower' as inflation, it can be useful for low to medium cost developments without all shareholders bearing the risk of failure. Also, the more BTS is worth, the more viable this strategy becomes for higher-cost developments. I propse this not as a replacement to the inflation model, but as an alternative development route for proposals with lower shareholder approval, which would not even get a chance. The deflationary aspect of this could help compensate for, if not totally reverse, inflationary development.
This could be the more DAC-like, less coin-like, intelligent successor to PTS.
There are probably many possible ways this can be accomplished, but here's a summary of the implementation I have in mind (holes and flaws most likely included; please critique!). Note that bytemaster's idea for 'DevShares' more closely resembles what I call 'DacShares', and what I call 'DevShares' is something completely different.
After reading, I invite you to join me on an experiment.
----------
DacShares and DevShares
I. DacShares
0. New user type: Developer
In addition to Delegates, users can register as Developers, with some sort of identity/credibility verification in place to make sure they are who they say they are. One registered developer may also represent a team of developers. Developer accounts will have special abilities which I will describe.
1. Issue Dac Proposal
Anyone (developer or non-developer) can issue a proposal for a new Dac. The proposal is stored on the blockchain (for Proof of Existence), and should be as detailed and complete as possible. Anyone can modify/fork their proposal and re-issue.
2. Developers apply for assignment
After a developer reads the proposal and decides he would like to work on this Dac, he applies to be assigned through a Developer Proposal. This application includes a bid of how much share of the Dac he needs to develop it (Developer Stake), including all share-claiming terms (lockout, milestones, vesting, etc). Developers can apply for their own proposal, and Developers can apply for another Developer's proposal.
(A 'Developer' can be a software developer or software development team, but doesn't necessarily have to be. Similarly, a 'Dac' doesn't necessarily have to be software. The proposal defines the requirements, and software may or may not be a part of it.)
3. Dac Proposal Voting
BTS holders vote on the proposal. If they like it, they simply vote 'YES', as well as vote for a Developer that submitted an application. Shareholders can optionally omit the Developer vote if they like the proposal but don't think any of the applied Developers are qualified. This may give incentive for more qualified Developers to submit an application. (Maybe voters can also have an optional 'requested developer' cast with their vote, which could show demand for a developer not currently applied. This would not be an actual vote, as they should have to read that developer's proposal prior to voting for him.)
4. Investment Phase
Once Dac Proposal votes achieve 'critical mass' (definition to be determined), it will be enabled as 'Active' status for a set time period. While a Dac Proposal is active, you can:
(Idea A) • Assign a number of your BTS to be investing for stake in this Dac. You can change this number at any time during the set time period (changing too often is discouraged by transaction fees). You can check your current allocation status at any time, however final initial allocation is set at the end of the Investment Phase.
(Idea B) • Send BTS to an investment address, entitling you to shares AGS-style
(Idea C) • Rules of investment distribution are not set in stone by the DacShares DAC, and can be determined by the voters in step 3. (Turing-completeness would help here)
5. Distribute asset
At the end of the Investment Phase, a new DacAsset is created and proportioned per account, also including the Developer's stake. All BTS included in this investment on all accounts are burned. All value transfers from the BTS to the DacAsset, unchanging BTS price and market cap as a direct result of burn/distribution.
6. Trading, development begins
Markets between the DacAsset and BTS open immediately. Developer is given the green light to start work, and his agreed distribution terms for the DacAsset are put into effect.
To retain value within the DacAsset, it is in the favor of the Dac to have all Dac operations be done in terms of the DacAsset. If a new BitAsset implementation were to be proposed, there would be trading pairs between BitUSD and the DacAsset, not BTS.
7. Dac Merger
After the Dac has matured, it will be clear if/when the Dac will add valuation to BTS if operations of the Dac can be done with BTS rather than solely the DacAsset token. Any BTS or DacAsset holder at any time can issue a Dac Merger Proposal, which outlines an distribution model honoring DacAsset holders new BTS in exchange for integrating the Dac functionality with BTS.
Voting for Merger Proposals on both sides (BTS and DacAsset holders) occur, and both need to achieve a 'critical mass' (again, definition to be defined). When this happens, all DacAsset holders are issued their share of BTS, all their DacAsset is burned, and the Dac's functions can now be operated in BTS.
If the DacAsset loses most of its value due to failure, only the DacAsset investors take the hit. This will effectively deflate BTS, and reward those who did not invest.
It is in the best interest for BTS shareholders to respect the DacShares social consensus, without backstabbing each other. If non-DacAsset-holding BTS holders see value in the Dac, collusion to merge the Dac into BTS without honoring the DacAsset holders will undermine the value of BTS itself, as it will discourage further development.
DacAssets also open the possibility for Dacs becoming successful, but remaining within BTS purchasable as a separate asset with no merger. This is perfectly acceptable, as long as it still adds value to the platform as a whole. They could even secede from BTS onto their own chain, however this is unlikely as the investor's voting and capital infusion is with the intention of adding value to BTS. (In other words, nobody is going to vote for or fund a Dac Proposal that imposes an apparent risk to BTS.) A mutually beneficial, segregated Dac within BTS could in fact be the most valuable inclusion model for that Dac's purpose.
II. DevShares
1. Issuance of DevAssets
Registered Developers are automatically issued their own DevAsset, which they by default own 100% of. When a developer is assigned and green-lighted to develop a Dac, the Developer Stake is distributed to owners of this DevAsset, in accordance with the share issuance terms agreed upon. A Developer owning all of his own DevAsset will always receive 100% of the Developer Stake.
2. Sale of Contracts for DevAssets
Developers can sell their DevAssets to any user in exchange for a Contract. The details of the contract can be defined by either party, and can vary in complexity. The simplest Contract would be: Developer sends X amount of DevAsset, buyer sends Y amount of BTS. A more complex contract would involve giving the developer leverage with matching BTS to DacAsset, up to a X number of BTS, in exchange for Y amount of his DevAsset (BTS would be locked up in collateral).
The developer needs to be very careful about the contracts that he agrees to, as a bad contract could destroy his ability to fund the development of any of his Dacs.
----------
Thoughts, Ideas:
• With the inflation development model, the negative effect of a failed Delegate is compounded because there are more shares in circulation for Dac that is worse-off. DacShares makes every situation a win/win for the health of the SuperDAC.
• Incubating new Dacs within BTS makes the Dac very comfy within BTS, while a Dac on a separate chain could be merged into a competing SuperDac with much less friction.
• A 'lazy' investor's best move is still to simply buy and hold BTS, as it is feasible that the majority of DacAssets will fall from their initial valuation. However, a more keen investor (and likely someone who just wants to gamble) has the ability to speculatively enter high-risk/high-reward positions with both DacShares and DevShares. All the while, BTS SuperDAC grows and becomes stronger.
• Maybe DacShares' voting phase and investment phase (I-3, I-4) could be combined into one Kickstarter-like crowdsale. The developer proposes a minimum investment amount and time period, and as long as it is above that amount, DacAssets are issued. If it is lower, everyone involved is sent back their BTS.
• DevShares make the value of Dac developers liquid on-chain. It also means Developers can now be 'Sponsored', which aids in Dac creation, and make their Developer Proposals more attractive.
• For DevShare contracts, locking up BTS in collateral until the Developer Stake is distributed is probably the healthiest for the SuperDAC, as it gives the developer incentive to apply for Dacs, and it enables another high-risk investment option for shareholders to potentially deflate BTS.
----------
I understand this is very complex, and the devs already have their hands tied. I think that the most appropriate thing to do is to pilot the system by using this system to build itself. It would mean that we'd have to do it off chain, of course.
Take this post as a Dac Proposal that I have just issued. If you think it could be improved, fork it and issue your own. If you think this Dac is worth building within BTS, simply post 'YES' anywhere in a reply. If you are a developer and would like to participate in building this Dac, post your Developer Proposal.
Let the experiment commence! Or let it fall flat on its face. Darwinian environments are great, aren't they?