DAICO and Coin Governance System: Differences and Similarities
A couple of months ago, Vitalik Buterin introduced the idea of a DAICO, a mix between a DAO and a ICO. It wasn’t the first call for the need of ICO post-governance, but thanks to Vitalik, it has become a hot topic in the Ethereum community. The idea behind the DAICO is to improve the relationship between the ICO launcher and the token holders, giving the token holders the possibility to recover their money if the ICO launcher doesn’t manage well the funds raised.
Apart from DAICO, there are other solutions to solve the problem of ICO governance. One of those solutions is the Coin Governance System, which I’m going to compare with DAICO to better understand their similarities and differences in this article.
1. Difference in integration of the governance solution
DAICO is proposed as an abstract idea. It is supposed to work in two different phases: contribution and tap mode. Even though it was proposed to be used in any kind of token sale(a capped sale, an uncapped sale, a dutch auction, a KYC’d sale, etc.), it is implemented in the smart contract of the ICO itself. This means that in order to turn an ICO into a DAICO, the launcher should change the code of their ICO to implement these two phases. So each ICO needs to do a new implementation of DAICO.
With the Coin Governance System, ICO launchers don’t need to change anything of their current ICO smart contracts. It doesn’t matter how they were implemented. The Coin Governance System is integrated as a separate module that deals with the governance after the ICO, so as long as the ICO moves its funds there, it will start working.
2. Access to the funds
Both DAICO and CGS use the concept of “tap”, in which the ICO launcher has access to a certain amount of wei per second until the smart contract holds no more ether. There is a small difference between both systems: in a DAICO, the tap starts at 0 and should be increased by the token holders by voting a proposal. In the case of the Coin Governance System, the tap starts at an amount specified by the ICO launcher.
This difference was introduced in the CGS so that the ICO token buyers can know in advance what the expected burning rate of the team is. It also allows the ICO launcher to plan in advance and avoids having funds locked forever.
3. Dealing with failure
When the ICO launcher is not able to keep the confidence of their token holders or if it turns out that the ICO was a fraud, both DAICO and CGS allow the token holders to redeem their money back, but there are some differences in the processes of redemption.
While a DAICO just needs part of the tokens holders to vote against the execution of the project to completely destroy it and gain access to the funds, in the CGS the process is divided in two steps and it doesn’t destroy the project.
- First, the ICO token holders need to open a claim by putting an amount of tokens on stake. As the allocation of tokens in every project is different, this amount is specified by the ICO launcher at the beginning of the CGS, so the token buyers can judge if is fair or not according to that project in particular. We recommend ICO launchers to set this amount to the 5% of the free float tokens.
- Once the claim is opened, the CGS arbiters perform a secret vote to decide whether the claim is grounded or not.
If both steps succeed, the ICO token holders will be able to redeem their tokens for the remaining ether for a limited period of time, but those token holders that still believe in the project can keep their tokens and continue supporting the project as before the claim.
4. Coping with “lazy” token holders
One of the main problems of on-chain governance is the low participation rates of token holders. Vitalik Buterin wrote a good summary on this topic.
One of the most illustrative examples is The DAO, in which the most voted proposals didn’t even surpassed the 10% of participation (not even those related with the security of The DAO itself!). As a reference, the quorum was set to the 20% of the token holders.
The other examples provided by Vitalik (with 17% and 30% participation rates) cannot be compared with DAICO because they use delegation in an approval vote only.
The formula proposed for the DAICO is as follows:
The axes of the graph represent the percent of token holders voting yes (vertical axe) or no (horizontal axe) in a proposal. If the result of a proposal lands on the green area, it means that the proposal passes. A proposal in the red area will not succeed.
With DAICO the are two types of resolutions:
- Raising the tap
- Permanently self-destructing the contract (withdraw mode)
If the token holders of an ICO don’t put too much effort in voting, the funds of the project will be permanently locked, as the tap starts at 0 and both types of resolutions require to pass a proposal. As a reference, I included in the image where would be the most voted proposal of The DAO. You can see all The DAO proposals here. Out of 71, only 5 had more than 1% of participation.
In the CGS, the tap starts at a value set by the ICO launcher. This value is transparent before the ICO, so token buyers know in advance the expected burning rate of the project. The process to open a claim by the token holders is done by staking their tokens with no time limit. It is comparable with the other examples provided by Vitalik in his article (with 17% and 30% participation rates), but with no vote delegation, so the recommended 5% of the free flow seems reasonable (it is actually configurable by the ICO launcher).
5. How do the DAICO & CGS deal with evil/greedy token holders?
As weird as it may sound, some people buy tokens just to make a profit and don’t care about the project behind the token. With this premise, it is reasonable to assume that these people will try to maximize their profit at the expense of the project.
Most projects divide their ICO in pre-ICO and public ICO with different discounts for each one. The public ICO is sometimes also divided in stages with up to a 30% discount over the final price. If you let these people exchange their tokens for the proportional amount of ether raised, those that bought with a discount have an economic incentive to do so.
The tokenomics and speculation are also problematic in this scenario. The value of the token will compete with the value of ether. This means that if the value of ether raises faster than the token at some point, these people will vote to withdraw their ether.
In DAICO, this means that these people will vote to permanently self-destruct the contract to withdraw ether with a profit, bringing the project to an end even before it started. The solution proposed to solve this issue, is to launch another DAICO. This solution doesn’t make sense, as the cost to launch another ICO is usually too high to even consider it and will require another token.
In the CGS this problem is solved by the role of the CGS arbiters, whose incentive is not related with the outcome of the vote. They don’t care about the price of the token/ether nor they hold ICO tokens. Their only incentive is to vote correctly if the project is doing a proper use of the funds in a claim opened by the token holders.
Another difference between DAICO and CGS is the period between claims/resolutions to avoid the spam. CGS has minimum of 100 days between claims to give the ICO launcher enough time to make changes.
But what happens if the CGS arbiters are the evil ones or if they are bribed?
First of all, the CGS arbiters cannot do anything to a project by themselves. They only act after a request (in the form of a claim) by the token holders. So both parties should be corrupted in order to manipulate the proper functioning of the project. Even in that scenario, they will not be able to permanently destruct the contract as in DAICO. They will only open the possibility for the ICO token holders to redeem their tokens for ether for a limited period of time. If there are still ICO token holders that trust the project, they can continue with their tokens.
To compensate the loss of ether in the scrow, the ICO launcher will receive the redeemed tokens after all the ether funds are used. So if the project continues its development, the total funding will be the same (or even higher) than the original received.
6. Coping with evil ICO launchers: DAICO vs CGS
The main issue that both DAICO and CGS try to solve is dealing with the “evil” ICO launcher, for example, an ICO that is a scam or an ICO launcher that just gives up on the project but still wants the money he raised for himself.
Most ICOs allocate a big part of the tokens to the company and the team. This is a bad practice, sometimes they allocate to themselves up to 30–40% of the total supply.
Due to the low participation rates in blockchain governance applications, an easy attack for an “evil” ICO launcher with DAICO would be to simply propose to raise the tap to be able to withdraw all the ether in one second. This attack can be minimized if the company and team has a proper vesting, but that’s not always the case.
With the CGS, the worst thing they could do is to force the failure of the project and open a claim to try to redeem his tokens for his own ether. This is also a bad outcome, but at least it will leave some ether for the ICO token holders.
Another possible attack comes from the control of the application itself. Although dapps use smart contracts to be decentralized, the interface used to interact with those smart contracts is centralized by the team behind the ICO. An evil ICO launcher could easily change this interface to trick his users to sign a malicious transaction to vote in favour of a proposal to increase the tap as in the previous case.
Imagine the following scenario: you are playing a cryptogame using Google Chrome and Metamask. When you try to use a potion on your character, a Metamask windows appears to sign the transaction as usual. Everything seems normal, no ether is going to be transferred, so you accept it to heal your character.
But there is a problem: the potion doesn’t work. The ICO launcher has changed the code under that button and you have signed the wrong transaction without noticing it. You have voted to increase the tap to an absurdly high amount.
With DAICO, this kind of attack is trivial for the ICO launcher. If it uses CGS, the most that could happen is that users are forced to open a claim. As the claim will be resolved by the CGS arbiters who use a different interface, the ICO launcher have no control over them. That claim will probably be discarded.
The future of ICO governance
No matter which governance solution you use in your ICO to protect your token buyers, it will be better than no protection at all. As we have seen, both DAICO and CGS are trying to solve the same issue but in a different manner.
So far it seems that DAICO is still in proposal phase, so many of the problems discussed in this article will probably be overcome in the future. It still needs to be formally defined and implemented to polish the details.
In terms of the Coin Governance System, you can read more about it in the whitepaper. It is already implemented, so if you want to be among the first to test it on testnet, join our Telegram channel.
Official CGS channels:
Telegram: https://t.me/coingovernancesystem
Website: https://cgs.vote/
Light paper: https://goo.gl/Ex8me6
White paper: https://goo.gl/y9gQ2W
Newsletter: http://eepurl.com/dmtBwD
Twitter: https://twitter.com/CGS_vote
LinkedIn: https://www.linkedin.com/company/coin-governance-system/
Medium: https://medium.com/coin-governance-system
Facebook: https://www.facebook.com/Coin-Governance-System-146771572657311/
Instagram: https://www.instagram.com/coingovernancesystem/
