The Vault

One of the products mentioned in my previous post has been finalized and work is already under way. It is our DAICO platform named Vault. Before getting into the details of what we are going to do with it, I will write a little bit about what a DAICO is, because a lot of people have not yet read about it.

Note: the following text is verbatim from Vitalik’s blog at: https://ethresear.ch/t/explanation-of-daicos/465

Benefits of a DAICO

The idea is as follows. A DAICO contract is published by a single development team that wishes to raise funds for a project. The DAICO contract starts off in “contribution mode”, specifying a mechanism by which anyone can contribute ETH to the contract, and get tokens in exchange. This could be a capped sale, an uncapped sale, a dutch auction, an interactive coin offering, a KYC’d sale with dynamic per-person caps, or whatever other mechanism the team chooses. Once the contribution period ends, the ability to contribute ETH stops, and the initial token balances are set; from there on the tokens can become tradeable.

After the contribution period, the contract has one major state variable: tap (units: wei / sec), initialized to zero. The tap determines the amount per second that the development team can take out of the contract.

The token holders get to vote on 2 kinds of resolutions:

1. Increment the tap
2. Destroy the contract and receive refunds proportional to your token balance.

Game-theoretic Security

Any vote is subject to 51% attacks, bribe attacks and other game-theoretic vulnerabilities, and any ICO is subject to the risk that a team will be irresponsible or simply a plain fraud. However, in a DAICO these risks are minimized, requiring both the developer and the vote to be compromised to cause any real damage:

• 51% attack maliciously raises tap — honest developer can just lower the tap again, or not claim excess funds
• Developer starts spending funds on lambos instead of real work — voters can prevent much of this by not raising the tap too much too quickly, but if it happens anyway they can vote to self-destruct
• 51% attack maliciously self-destructs — honest developer can just make another DAICO

Notice how two of the potentially most harmful kind of 51% attack: (i) sending funds to some other third party chosen by the attacker, and (ii) lowering the tap to keep funds stuck in the contract forever are both simply disallowed by the mechanism.

Signal Flow

Our take on the above method:

Let me get into a few things that I learned from talking to ICO issuers(devs, companies) about the above method, then I’ll get into how exactly we are departing from the vanilla model in our DAICO platform.

1. Malicious self destruct: Vitalik has sort of brushed this away with ‘can do a new ICO’, but doing an ICO is not easy in the first place — legal costs, marketing costs, branding efforts, are all costs that come out of companies’ pockets. Destruction of ICO leads to automatic refund to investors and the project will now have to get into a marketing nightmare to get investors to send their funds back into their ICO contract. Projects get one shot at raising ICO and going back to the community for resending the funds after a malicious attack is most likely going to be a disaster for the project. Not only do these costs have to be borne again, but people are also more prone to move on to the next big ICO, instead of reinvesting in a DAICO which was attacked. Furthermore, the refunds that each individual will get could end up being far far lesser than the token value they were holding. Because funds in the contract are lesser than total collected funds, and market cap is typically 5–10x the collected funds. This would destroy any individual investor who bought a large enough share from the secondary market. We see this as an extremely serious flaw, and try to address it — we firmly believe that DAICOs will never be a popular option if such a thing can happen.
2. No One Time Proposal: The model proposed above is just a basic outline, and Vitalik has encouraged the community to make improvements. One necessary improvement to the concept is to have One Time Proposals. If there is a certain tap, and the company needs to withdraw some money to get an exchange listing, or if the project happens to need an unanticipated infusion of liquidity for business expansion, what option do they have? The company is forced to ask the crowd to increase the tap, which they cannot later on decrease. This is a weakness in general. A simple solution is to have consensus driven withdrawals which bypass the tap for a single withdrawal of a preset amount.
3. No accountability: The KYCing of addresses nowadays enables us today, to make sure that one individual can vote only from a single address. While it is not completely impossible to bypass such checks, these methods are getting better. At some point of time, such methods will be capable of enabling DAICOs to know the levels of wealth concentration across individuals and not across addresses as the plain blockchain data would suggest. This would empower a DAICO to detect malicious accumulation, act in advance, and keep automated guidelines, and non linear voting curves.
4. Liquidity vs Governance: Governance on the blockchain requires people to stake tokens in an address whose private key they own. A lot of people keep their coins on centralized exchanges. While it is not perfectly secure, there is an understandable reason for this. Most token markets are illiquid, and when prices rise, the opportunity to make a profit is a short window of time. If investors will choose liquidity over security, they might choose liquidity over governance. If a community has to be encouraged to govern, there needs to be some integration with a DEX which will allow investors to liquidate their holdings when needed. This very well may be the reason for failure of the initial DAICO platforms. We are about to find out in the coming months.
5. Step-Function Governance: Some of the dev teams I talked to expressed the desire for a different kind of system. They all appreciate a system which can weed out scams, however made the valid point that life isn’t linear, and maybe a DAICO cash flow shouldn’t be either. A model alternate to the Linear-Spline DAICO(this is what we are calling Vitalik’s DAICO) is a system where the ICO token issuer announces in the whitepaper their quarterly or monthly(or otherwise periodic) expenses before collecting funds, and the contract automatically releases the pre decided funds on the declared dates. The governance pool has no role in deciding the tap, because there is no tap, however the governance pool may vote for a self destruct if the project turns out to be a scam. One time proposals will simply bypass the cash flow pattern and subtract the amounts from the payouts that are most far ahead in the future.
   Edit(early october): This system has been deprecated, upon the introduction of a new feature called ‘initial fund release’. This is due to the fact that majority of the issuers reluctance with linear spline DAICO had to do with the fact that initially no funds are released. By adding an initial bump to the tap-time curve, we eliminate the need for step function DAICOs altogether.

Key departures from the original proposal:

With the dispositions described above, we proceed to make a number of distinctions in our DAICO platform.

Membership protocol is layered on top of token ownership

1. Membership based: You would have to be a member of the Vault ecosystem in order to partake in governance, and simply owning tokens is not enough. I can already hear the decentralization maximalists coming for my head, but hear me out first. This is not a membership which someone sitting in an ivory tower would grant you. Firstly, anyone can get a membership, if they are KYC’d with our KYC partner(to be announced). They are like any other blockchain ID vendor, and your identity is stored offline and secure. When you sign up to be a member of Vault, we don’t take your data, we only verify that you are who you claim to be, and that you have already not registered with vault under a different blockchain address. If those two criteria are met, you get a membership, no questions asked. Secondly, what you are getting here is not like a binance account. This is better, because your funds stay in your own wallet, with your own keys. What is the benefit, you ask? Cool, so first of all, once you are recognized on Vault, whitelisting for future ICOs will be a simple click. Secondly, knowing that each governor is a unique individual and nobody has 2 accounts, will help the system serve YOU better. Would you rather be hit by a 51% attack? These facets will be explained in this post. Also, with whitelisting, token generation, liquidity and governance on the same screen, you will have everything on one website, without having to forfeit access to keys like binance, or enduring horrible UX like IDEX. In that matter, our philosophy is very similar to that of Kyber Network.
2. Addition of step-function DAICOs: We have decided to allow ICO issuers to choose between the format of their DAICO, one option being linear-spline DAICOs, as suggested by Vitalik, and the other one being step function DAICOs where the issuer commits on the blockchain their withdrawal schedule, and level of consensus required to kill off the contract. The linear-spline ICO gives investors more control over the dev teams and hence, is better for investors. However teams with proven track records and reputations to uphold might not necessarily need to be chained in so strictly in order to ensure proper usage of funds. The step function DAICO operates as follows:
   1. Issuer reveals their projected expenditure and gives a proposal for quarterly withdrawals with detailed descriptions of where they will be spending.
   2. These withdrawals are committed into the smart contract of crowdfunding.
   3. Withdrawals happen at the stipulated times, except if the contract gets killed. All remaining funds are then refunded and no more withdraws will be possible.
   4. In the event that the company has some unforeseen expenses, they can petition for a one time exceptional withdrawal(this can be done several times, the name says one time because it is an exception to the rule), which is passed only if the governance pool votes in favor.
   The details of the spend spikes will be transparent before the ICO and shown on the pre ICO dash board on Vault.
3. 51% attack prevention: This is the most striking departure from the vanilla DAICO model. The first measure taken to prevent 51% attacks is to cap individual vote shares. No individual should be able to control huge staggering majority of governance on a DAICO. The issuer sets a individual vote cap during issuance, and the governance contract will disregard any excess token holdings in an address beyond a certain threshold(say 0.5% of total tokens). This can be bypassed by an individual if they have multiple addresses under their control in the governance pool(eg. I distribute 50% of all tokens in 100 addresses owned by me). This is where the membership criterion comes in. This is exactly why we do not want any unknown address participating in governance. This reduces greatly, the options of an individual or group willing to maliciously attack a contract. The only option available with a malicious group is to then bribe a large number of real individuals and convince them to cooperate in the attack(in addition to themselves buying up huge supply of tokens/refunding the loss of value from contract kill). This method can be undertaken either secretly or publicly. In case of a public attacker(smart contractual), the network becomes aware that there is an attack effort, and steps may be devised. In the event of secret attack, a more nuanced solution is needed, which brings us to the next departure from the vanilla model.
4. Health indicator and statistics: Vault will provide on the governance dashboard a health indicator. This health indicator will be a number that gives a picture of holder concentration. The number is calculated by looking at the number of top holders in the governance pool(vault members) that add up to 51% of the voting share. This is the perfect health indicator as it gives away the minimum amount of collusion(difficulty) required to carry out a 51% attack. When this number suddenly drops, it is a cause for worry. A time plot of this number is an excellent indicator for detecting a ‘secret coup’ of the contract. Moreover, Vault will provide a vote share histogram that gives the distribution of votes across participants. This may not directly give any conclusions about 51% attacks(other than how much you need to have to belong in the top 51%). However, we believe that human beings are visual creatures, and over time, analysts will come up with methods to use this data to anticipate certain developments. All of the tools above make use of the fact that a membership is necessary to make governance decisions. A non custodial(we don’t hold your tokens) membership doesn’t like a very bad idea now, does it? Although this pretty much covers up the ‘anticipation of attacks’ side of the issue, we are still discussing how we want to go about acting upon such anticipation. The obvious thing to do is to revoke memberships from malicious actors. The big question becomes — who will decide who is malicious? I will deal with this question towards the end of this post.
5. DEX Integration: We have decided to integrate the governance dashboard for each token(subject to listing) with Kyber, so that investors can sell off or buy more of the token by using a simple modal that opens up from a single click. The intent is to make more people take part in governance, instead of parking their tokens in an exchange for liquidity.

About action on anticipated attacks, here is a solution:

A 51% attack becomes more costly(financially and operationally) as the number of people needed for collusion increases. The vote-share cap already ensures that the number of people required for a 51% attack is greater than (50/cap) where cap is the percentage cap on vote-share. However a contract can further be strengthened by requiring a kill to have not only a higher threshold for killing, such as 80% of votes, but also requiring a minimum number of individuals to vote in favor of killing. If we let the issuer set this number, this allows them to choose how secure they want their DAICO to be. However if this number is too large, it will make the DAICO impervious, which is a bad practice. Whether we want to standardize this number or allow the issuer to choose it and then make it transparent, is a management decision we are yet to make.