Author Topic: Deflationary Development Model -- Join my experiment  (Read 7055 times)

0 Members and 1 Guest are viewing this topic.

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
a visual diagram of this  Devshares   Dacshares    Dac kickstarter/ incubator proposal would be very helpful.

Perhaps if byte master likes the idea he can tweak it and give us a nice visual diagram.

Sounds good so far.  I'm a little unclear as to how devshares are created and a developer has 100% of his own devshares to exchange for bts to begin developing his Dac.  I guess my question is where are devshares created in the process?   And is bts burned to create it?
Devshares are worthless and a certain qty is created if proposal is voted in. Once funded now the devshares become worth something.

You may not need bts to do anything here until the dac merger process which is a process that is known as part of the original proposal by Bytemaster so he doesnt have to really do anything to change the bts code to support this. You can create a random pub key from a new random private key to send bts to so you may burn funds.. However the supply will not shrink so this isnt the greatest thing but it will do the job.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
I can see how it would benefit BTS holders through share burn/buyback if we somehow convinced people to do this, but I don't see how the burn is desirable to the actual participants.

The proposal submission and developer bids make sense, but it seems like it would be more efficient to use a decentralized kickstarter model.  You could use the same basic system for proposals and developer bids, but once a bid was submitted a funding period would start for people to commit pledges into escrow.  If it fails to fund, they all get their funds returned, otherwise the development period starts and the funds remain in escrow.  At the end, the investors can vote to either pay the dev the balance, or burn it if they think they've been scammed.
That sucks.. Devs need funds upfront. Also everyone would get the feature and vote to burn at the end. Not sure but not quite as good as op proposal.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
I can see how it would benefit BTS holders through share burn/buyback if we somehow convinced people to do this, but I don't see how the burn is desirable to the actual participants.

The proposal submission and developer bids make sense, but it seems like it would be more efficient to use a decentralized kickstarter model.  You could use the same basic system for proposals and developer bids, but once a bid was submitted a funding period would start for people to commit pledges into escrow.  If it fails to fund, they all get their funds returned, otherwise the development period starts and the funds remain in escrow.  At the end, the investors can vote to either pay the dev the balance, or burn it if they think they've been scammed.

Offline mbaeichapareiko

  • Full Member
  • ***
  • Posts: 59
    • View Profile
a visual diagram of this  Devshares   Dacshares    Dac kickstarter/ incubator proposal would be very helpful.

Perhaps if byte master likes the idea he can tweak it and give us a nice visual diagram.

Sounds good so far.  I'm a little unclear as to how devshares are created and a developer has 100% of his own devshares to exchange for bts to begin developing his Dac.  I guess my question is where are devshares created in the process?   And is bts burned to create it?

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Good idea, also it should cost to put forth a proposal because people should really think before creating proposals otherwise you will have a flood of investment ideas to try to get funding... so a large fee should help filter out people not certain they want to go ahead and create a proposal.

There shouldn't be a manual filter in place, because once a proposal is in place it should be either voted in or voted out. Then the fundraising starts.

Seems there are 3 use cases:

1) Voting in an inflationary proposal for marketing or something else... in your examples the inflationary ones were ones the company would create. Can you think of an example of an inflationary proposal that would be simply voted in without creating a dac for it to issue shares? Remember the company is being phased out. So maybe this one will stop after the company is gone.

2) Voting on proposals which create a DAC to issue shares... Once approved and enough funds are raised the DAC issues shares to investors... investors hope it gets merged into BTS as there has to be a clear risk:reward set up here and it should be defined within the proposal (turing complete scripts would help here for when the merging is done and % of inflation is applied for example). If vote doesn't succeed how many kicks at the can will they have to try to get it merged?

3) So in 2, essentially the motivation for investors is that they will vote in and invest in ideas that may be merged into BTS.. the superDAC. But if the DAC stays as a seperate DAC, it needs to be monetized and thus the proposal would define how it is monetized to judge if its profitable, and give back profits to shareholders... Is it possible to have a DAC give profits to shareholders based on operating profits in a trustless way, again maybe turing completeness helps here?

« Last Edit: October 23, 2014, 03:26:51 am by jsidhu »
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
The key advantage inflation has, is that you can sell new shares immediately on the market. With DacShares, you will have a much more shallow market for your DacAsset until there is increased demand (if that ever happens).

I've been thinking about this more, and I realize that to fund development, the Developer needs his funds to be liquid (i.e. BTS). For this reason, a Developer can choose to receive a percentage (0% to 100%) of his Developer Stake in BTS instead of DevAsset, taken from what would have been burned. The DevAsset that would have been issued in this percentage via burn is simply not issued. This solves the issue of the developer needing to sell his DevAsset on a potentially illiquid market.

Take this example:

- 1,000,000 BTS are invested in Foo Dac (Let's call the DacAsset 'FooShares').
- 1,000,000 FooShares are to be created/distributed.
- The voted Developer assigned to the project is to receive 5% of FooShares, and 5% of BTS.
- The Developer receives 50,000 FooShares, and 50,000 BTS.
- Since 50,000 BTS were not burned, 50,000 FooShares are also not created
- 900,000 FooShares are distributed to the BTS investors

As you can see, the Developer basically sold 50,000 of his FooShares for BTS at the market price to the rest of the FooShareholders, determined by the number of BTS invested (1 FooShare = 1 BTS).

Offline GaltReport

Essentially you would replace the capital infusion with captial diffusion? WHoever wants to invest in ideas can do so to try to gain more than by just holding? Similar to how our economy works today? Brilliant. I like it. With Turing completeness I hope something like this can be done without any manual intervention of funds.

Wouldn't this type of strategy replace what that current proposal is because of the burning BTS part?

As I said, it's not exactly a replacement. I think they're complimentary. Inflation can be used for high-cost lower-risk initiatives that have a high degree of concensus among shareholders, while DacShares can be used for higher-risk, lower-cost, and low consensus Dac add-ons. Some examples:

Viral marketing campaign: Inflation
Associated Press Dac: DacShares
Purchasing a Credit Union: Inflation
Atomic Cross-chain trading: DacShares

The key advantage inflation has, is that you can sell new shares immediately on the market. With DacShares, you will have a much more shallow market for your DacAsset until there is increased demand (if that ever happens).

Another thing to note that successful DacAssets ultimately can lead to inflation as part of the Dac Merger process. However, I am guessing that many DacAssets will not rise above their issuance price, and either will not be merged back into BTS, or will be merged back at a discount.

Very nice.  Genius really!  Great alternative/compliment.  I like this part especially:

"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."

This is good risk mitigation.
« Last Edit: October 23, 2014, 01:09:51 am by GaltReport »

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Makes sense.. and I think this way there probably would be (hopefully)  more burning than inflating per year.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Essentially you would replace the capital infusion with captial diffusion? WHoever wants to invest in ideas can do so to try to gain more than by just holding? Similar to how our economy works today? Brilliant. I like it. With Turing completeness I hope something like this can be done without any manual intervention of funds.

Wouldn't this type of strategy replace what that current proposal is because of the burning BTS part?

As I said, it's not exactly a replacement. I think they're complimentary. Inflation can be used for high-cost lower-risk initiatives that have a high degree of concensus among shareholders, while DacShares can be used for higher-risk, lower-cost, and low consensus Dac add-ons. Some examples:

Viral marketing campaign: Inflation
Associated Press Dac: DacShares
Purchasing a Credit Union: Inflation
Atomic Cross-chain trading: DacShares

The key advantage inflation has, is that you can sell new shares immediately on the market. With DacShares, you will have a much more shallow market for your DacAsset until there is increased demand (if that ever happens).

Another thing to note that successful DacAssets ultimately can lead to inflation as part of the Dac Merger process. However, I am guessing that many DacAssets will not rise above their issuance price, and either will not be merged back into BTS, or will be merged back at a discount.

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Essentially you would replace the capital infusion with captial diffusion? WHoever wants to invest in ideas can do so to try to gain more than by just holding? Similar to how our economy works today? Brilliant. I like it. With Turing completeness I hope something like this can be done without any manual intervention of funds.

Wouldn't this type of strategy replace what that current proposal is because of the burning BTS part?
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile



Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
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?