Explanation of DAICOs

Could you give me some names, please?

Thatā€™s a great idea, and more so as a starting point for a larger shift needed.

Note that thereā€™s a couple different goals in here:

  • Reduce investorsā€™ unnecessary risk (and potential ICO scams)
  • Decentralize the team to induce efficiency, scale and wisdom of the crowds

Also note that thereā€™s two kinds of ā€œbad ICOsā€ to protect from:

  • Complete pump-and-dump scam, Lambo ICO.
  • Teams with no/bad product but with great marketing machine, that can raise huge amount of money, drive up token price for long enough, and eventually cause large losses for investors. (And Iā€™m looking at quite a few 10-11 digits (!) market caps of this sort right now. This is unbelievable and a significant source of the coming explosion).

So as said, the above model is a pretty good starting point, but achieving a significant improvement from the current status quo (by achieving the above two goals to good degree) will require some modifications, and in particular the following two things:

  • Almost any important modification will require some decentralized governance system; itā€™ll need to be efficient, resilient, and at scale.

  • Itā€™d be probably impossible to nail the ā€œrightā€ working model on the first iteration (thereā€™s too many degrees of freedom to play with, and too little certainty; also, it might be that thereā€™s no one model that fits all). Thus, would need to have a pretty generic ā€œgovernance systemā€ that can easily evolve, be played with and be upgraded.

A few simple modifications to the basic model (thereā€™s many more complicated ones):

  1. The model is actually vulnerable to 51% attack of the team itself. If the team has access to large capital it can buy 51% of its own tokens, raise a lot more money, and then control the tap and get everything out (unfortunately this is a real use case played today in the industry).

One way to improve on that is to allow individual token holders to pull out their relative share, pro rata (mentioned above) at any time. It gives more investor control of their money, but the downside is that it also creates higher instability for the dev team fund, limiting possible long-term planning.

Possible solution: token holders can only pull out, say, 80% of their ETH share against full token redemption, while the remaining is shared between the remaining token holders. That makes the ā€œredemption rateā€ going up upon redemption ā€“ rather than kept intact or going down ā€“ which induces stability against mass withdrawal.

  1. On the other hand, to even further secure long-term planning founders (and yearly costs), letā€™s say the team can withdraw an initial budget of 5% of raised capital at the beginning; and further burn rate (the ā€œtapā€) as suggested. 5% initial withdrawal might not make the whole effort (and its internal costs) worthwhile if being a scam.

  2. Thereā€™s a need to allocate the project tokens to the team (most dev teams would not be interested just in funding, but also in stake in their own project). The simplest option is to allocate a trench of tokens to begin with (say, 30%), but ā€“ unless itā€™s a fixed team ā€“ would need to continuously allocate those tokens to further contributors. This requires a good governance system, and preferably one based on reputation rather than on stake.

As mentioned, there are many more tweaks, and the best way to explore them all is via real-world experimnetations.

Finally, the above suggestion is a great step ahead. The next big steps would be to come up with:

  • a complete decentralized governance model; efficient, resilient and at scale.

  • a fully generic governance system/platform; universal, modular and upgradable.

  • the implementation of the former on the latter; and many small tweaks to initiate its evolution.

Fortunately thatā€™s what weā€™re building with the DAO stack, and a first public system will be ready on the main net in Q1.

@vbuterin

2 Likes

Exploring the Game Theory side imagine a scenario where an incumbent sees a project that attacks their market share and that the project is funded by a DAICO. The incumbent could buy (through stealth addresses or otherwise) > 51% and with the proposed model kill funding for the project.

The developers could self-destruct the contract at this point, return funds and start a new DAICO but there is nothing to stop this process repeating.

Mitigating this might involve

  • a minimum tap rate for a mimimum period of time to ensure that there is some economic disincentive to this.
  • escrowing a small percentage of tokens to be returned to devs in the event that a dao kills funding.

If I am a cash rich attacker there is nothing to stop me choking DAICO funded startups and eventually getting my stake back. Otherwise great work :grinning:

5 Likes

Our thoughts on how any fair and responsible ICO should be performed are very much in line with the DAICO model. We immediately created the first implementation of a DAICO modelled ICO contract.

To be able to implement DAICO into a real-life ICO environment, we have integrated it into our open-source framework: decentralized & responsible ICO ā€œRICOā€. RICO was developed so that developers can flexibly design various ICOs and run them completely on smart contracts.

For the specific implementation of DAICO in an ICO we have created the architecture as follows:

Contribution mode

Currently, we support the following methods:

  • Capped sale
  • Uncapped sale
  • Dutch auction

With RICO we utilize a modular system called Proof of Donation (ā€œPoDā€). PoD is modular in the way that a function can be called upon the timing of donation, making it easy to expand the functionality of your ICO. As a result, other formats (e.g. Interactive Coin Offering, a KYC sale) can also be supported.
This time, we implemented the specification as DaicoPoD, and it is assumed to be used with other Proof of Donation base contracts.
You can see the DAICO PoD code here:
https://github.com/DRI-network/RICO/blob/daico-pod/contracts/PoDs/DaicoPoD.sol

How to vote

The method of voting is to deposit your ICO tokens into a special voting contract.

  • A voter must deposit at least 15,000 tokens to participate in the voting process (this amount is an example. The optimal amount of tokens need to be examined in the future)
  • All voters must call a voting function during a set voting period.
  • The tokens of the accounts that participated in the voting will be locked for that period. (Withdrawal impossible)
function vote(bool _flag) public returns (bool); 

Proposing a vote (Raising the tap or go into Withdraw mode)

In order to raise the tap or go into Withdraw mode, you need to send a proposal to the contract. To do this, create a new proposal using the submitProposal function. This function can be executed after the previous proposal has been aggregated. In order to be able to execute submitProposal, an account must deposit a minimum of 30,000 Token to the contract. (This token quantity is an example.)
The aggregateVotes function can be executed by anyone after the voting period has ended. Based on the aggregation result of the proposal, the tap is raised or shift to withdraw mode.

The submitProposal and aggregateVotes functions are implemented as follows:

function submitProposal(uint256 _nextOpenTime, uint256 _nextCloseTime, uint256 _nextTapAmount, bool _isDestruct) public returns (bool);
function aggregateVotes() public returns (bool);

The parameters are as follows:

  • nextOpenTime: Start time of voting for new proposal
  • nextCloseTime: End time of voting for new proposal (nextCloseTime must be specified at least 7 days after nextOpenTime)
  • nextTapAmount: Amount of tap to be effective with a new proposal
  • isDestruct: Whether this proposal aims to shift to Withdraw mode (eliminating the fund)

Withdraw mode

If the withdraw mode is passed in a voting, the contract prohibits any new token deposits.
Depending on the balance of the tokens already deposited, it is now possible for token holders to extract ether.

uint refundAmount = this.balance * lockedTokenBalances[msg.sender] / token.balanceOf(this);

Risk

Proposal lock

As a matter of concern, if a malicious user has an account that is able to execute submitProposal, it is possible to intentionally continue to submit malicious proposals after each other to the contract. It might be required to add the functionality of certain discipline algorithms (e.g. Slasher, an appropriate burn model).

-ā€”-
You can find all our DAICO and RICO related code here(daico-pod branch): https://github.com/DRI-network/RICO/tree/daico-pod
Note: This architecture may change in future.

We are waiting for your comments and contributions!

3 Likes

Even the DAICO model tries to fight proven models and will probably fail. I still think the path of least resistance involves private financing, followed by a ICO liquidation event. The private funding stage should build out a product which can live on its own in a decentralized universe, while the liquidation event provides investors an opportunity to sell the good / service to customers who will actually be able to use the token. In a frictionless decentralized system, thereā€™s no reason to hold onto a means of exchange token, which all ICOs represent, unless you intend to sell / spot them to users and purchasers. I mean, would you hold onto a bunch of arcade tokens, hoping that you could get to play more games with those same tokens in the future? What makes more sense is to have a few private investors (and core team developers) receive tokens in exchange for their investment / services, and then have those token holders go out and compete to sell tokens to customers.

If people are willing to pay 5x ICO price, it means in a way that at least some aspect of the project is attractive to them, except if itā€™s a ponzi-like scheme.

This is not necessarily true, there are many examples in the traditional startup industry -Theranos is a good example- and Wall Street, it could be just that investors fell for the sunk cost fallacy or theyā€™re just trying to boost the price of the token so they can dump it before the company fails, if reducing the tap will make the token price drop, investors wonā€™t have a financial incentive to do it, at least not up until the very last minute, so I agree with @nisdas in this point

If the tap amount influences the token price in the exchanges, investors will not have an incentive to reduce it, specially at the beginning of the project where is hard to evaluate the performance of the team. Then as time passes by and more money is in the hand of the developers another issues like the sunken cost fallacy will come into play, reducing those incentives even more.

In addition if the project is advanced and a good part of the investment is already in the hands of the developers and the investors have insider information that lead them to believe that the project will fail, investors may have the incentive to raise the tap in order to inflate the price just before dumping the tokens in order to recover the money thatā€™s already lost.

There are many examples of these behaviors, Theranos for example, while valuation kept growing most of the investors basically ignored the performance of the company, and then even after the crisis started they gave her more money trying to save their investment or at least part of it.

As @nisdas said, I also think this model relies too much on the players being rational and honest, a solution could be to instead of getting all the money during the ICO, investors are given a right of first refusal on monthly sales and the right to vote on the tap rate, so they have the incentive to keep the token price low so they can continue investing and high so previously bought tokens keep gaining value.

1 Like

Just to play Devilā€™s Advocateā€¦ what happens if no one solves the Lambo ICO problem? I think that investors will get scammed, over and over again until they become more risk adverse. Eventually ICO investors will want to know more about projects and perform deeper investigations of teams. Teams that want to be successful with their ICO will need to satisfy these newly risk adverse investors that they are who they say they are and that they will do what they say they will do.

To look at it another way, what is the true underlying problem you seek to fix? Is it that many unscrupulous people are launching ICOs and making off with the cash? Or is it that naive or risky investors are continuing to fund the teams that will eventually run off with the cash? If the true problem is the latter then I think we are currently seeing the market do what it is supposed to do. It is punishing risky investments. Sure, itā€™s also rewarding sociopaths, and no one wants that, but the lesson is the same.

A colleague read through this and mentioned that he thought it would incentivize teams to perform leveraged buyouts of the tokens to gain 51% control. In reality that might just cost too much money and require more tokens to be available for purchase than is realistic, but it is still a theoretical possibility.

I suppose another way of looking at this would be to ask what value a well functioning DAICO would add to the ICO market? It would increase investor confidence, theoretically bringing in more investment money. But lack of investment capital isnā€™t a problem, is it? If it worked well it would short circuit bad actors, which is clearly a positive, but that would the effect of that be? I guess it would mean that someone like me could invest without investigating as much. I would have the confidence of the DAICO governance so I could just sit back and feel that my money is protected. But that in turn will result in less engaged investors - or least allow for the comfort of less engaged investors.

Itā€™s an interesting problem, but this solution might suffer from being too tied in to the current context of the ICO marketplace.

Really like your arguments! We are doing something similar at https://incremint.io/

You are spot on for identifying edge cases that may never fit in the ICO/DAICO model.

I also agree with you about Ethereum to focus on scaling and not governance. That said, this kind of framework needs to be designed for creating a space to fund execution of more ideas that normally would not get traction. Ethereum brings a wider audience to fund an idea and so governance is going to be part of it, but how far the governance goes in fueling an idea is the question.

Also a marketplace like Angelist to meet basic guidelines focused on identity and verifiable information before launching is ICO/DAICO has to be a must. Call it a ICO/DAICO registry that directly links projects to the token instead of relying on 3rd parties and fraudulent sites that are spun up independently and are very difficult verify.

Well, the thing I think is the most valuable is avoiding over-regulation, the market may be punishing risky investments but it may force the government to take action, specially if the number of risky investors are too high, and when this happens governments tend to overregulate.

1 Like

Thatā€™s a good point that I hadnā€™t considered.

For entrepreneurs, ICOs provide a refreshing model for capital formation that reduces exposure to activist investors. In practice, most people probably agree, we need to strike a balance between stakeholder and team control to reduce Lambo ICOs and exit scams which has leads us to fixate on lowering team control. Itā€™s easy to forget; investors can be just as greedy as entrepreneurs and developers. Giving the power to someone else does not solve the problem. Blockchains work by diluting power and inhibiting its concentration.

The critical issues with ICOs are 1) teams are raising irresponsible amounts of capital without delivering a product or demonstrating competency and 2) tokens are listed before products are available. The visceral response seems to be a desire to move control away from the teams, but DAICOs open the door to activist investors that plague the legacy system and force companies into short-term (quarterly) thinking. The key problem is not investor control but rather a premature listing of tokens which incentivizes short-term investing, creating bubble thinking and fueling investor greed.

DAICOs will only extend the phenomenon and, in extreme cases, will incentives investors to liquidate the company if the price of ETH outpaces the ICO token. Innovation is hard, and it takes time to run experiments and refine products.

Instead of giving control to the investors, we need to change the incentive system to reward long-term thinking and investment strategies. ICO teams should plan to conduct more fundraiser rounds and delay token tradability until after the company matures. This solves the Lambo ICO problem and delays the liquidity point for investors which encourages more responsible and long-term investing. Investors need to know they are funding innovation and it will be a long time before they can access the asset. They should seriously consider if it is worth locking up valuable ETH to support an unproven idea.

5 Likes

The core issue that I see here is a practical one: devs need to pay their service providers, partners, employees in fiat. Even if they donā€™t need to pay them in fiat, then the ETH payment will still reflect the corresponding value in fiat. E.g. a developer might be fine getting their salary in ETH but if the USD/ETH rate crashes 95% then theyā€™d probably not like the terms anymore simply because they canā€™t pay their bills. IMO, ETH is not going to be a practical unit of account in the mid to long-term future. Hence people running a responsible business are cashing out large amounts of ETH to manage their liquidity. This is not going to work in the proposed model and does require some form of stable token. Even globally ā€œstableā€ token might still fluctuate a lot relative to the most relevant unit of account, e.g. to CHF for a Swiss-based team. Hence Iā€™m still interested in central bank issued tokens for some applications (hedging).

2 Likes

I really like the idea, but I think this is only applicable for companies that can rightly be described as DAOā€™s. Many companies using ICOā€™s have large portions of their infrastructure and business model off-chain, thus rendering any take over merely a ā€˜burn it all downā€™ attack which reduces even the value of their own coins down to nothing. I really like this idea for governance for truly decentralized projects (e.g. Ethereum) in which the network can subsist without the founders or off-chain components. If you imagine a true DAO, then this could be used very well to incentive developers or even the founders who are doing marketing and/ or contributing to the bulk of the progress/ research to the network.

What if the team itself raises the tap value by vote manipulation (e.g. P + epsilon)?

The scheme does not have infinite security; as I mention, if both the vote mechanism and the developer are corrupted, then DAICOs do not solve the problem. But this is much less likely than just one of the two having an issue.

1 Like

It is though more common for founders to be screwed by the VCs then the other way around, http://www.businessinsider.com/this-22-year-veteran-of-startups-says-employees-are-getting-screwed-by-vcs-and-ceos-2014-3, I know the link is old but not much has changed :), so is not the question for the investor to know how serious the founder is to create and sustain the startup he is announcing to the ICO investors ? And for the founder to have stable founding without getting screwed ?

As then for the investor it comes down to Due Diligence as any serious founder will be very ā€œOpen Kimonoā€ about who he is and why you should trust him and his team, and of course be interested in his product.

Then I believe in the concept of rounds, as from day one and 6 months you can only do so much, and there are certain milestones to hit, then there is a second round, and still the proof is in the pudding, do or donā€™t get funded.

Anyway just my two cents

We are working on a similar project with some additional options/functionalities: https://incremint.io/. Have been having great feedback from the community on the need for the escrow mechanism.

Wouldnā€™t this be even more effective if matched with the Gitcoin project whereas voting could be done either on weekly sprints or even on open development tasks and funds are allocated accordingly?

I tried to write my thoughts here: https://medium.com/@martin.maurer/seed-ico-keeps-greed-at-bay-10c4b4fbd2bc

and we started to work on it here: https://github.com/empea-careercriminal/super-octo-engine/blob/master/SeedIco.sol

while thinking about a better way to organize funding for our upcoming projects.

The concept is very similar to the DAICO, but aims at making any project you start with it a ā€œpurpose drivenā€ one while giving investors some freedom to chose if they really want to see the project succeed or if they are in mainly to sell their tokens with benefit.