Initial Coin Offerings(ICOs) have been killing it as a new way to raise funds. According to the report by PWC, more than five hundred projects raised more than a total of seven billion dollars in 2017. Furthermore, in 2018, the total amount is twice that of 2017 in only five months.

 

Unfortunately, as you may be fully aware of, there are scams and fake pledges that have caused economic losses to investors(Satis Group has reported that more than 80% of ICOs are scams).

 

Reflecting such a situation, Vitalik Buterin, one of the founders of Ethereum, proposed the concept called DAICO in this January. The DAICO model allows token holders to assert meaningful control over the funds, hence minimizing the risk of investing.

 

At ICOVO, we implemented this DAICO model, and made it open-source as DAICOVO framework. Anyone can use this framework freely, and start their ICOs with the DAICO system.

 

DAICOVO

 

Our goal is to provide the healthier ICO practices. To that end, we build the platform where investors can participate in ICOs with ease. The DAICOVO is more than just an implementation of the DAICO concept in a sense that we provide practical functions and parameters that can meet the needs of each ICO.

 

In this series of posts, I’m targeting engineers who want to understand the DAICOVO smart contracts in depth and token issuers who are considering ICOs with our framework. I will explain the whole process and each smart contract in detail. I will also mention things we have considered in the process of developing our framework. Please note that this series is based on the Ver.1.0.0. We will keep updating our framework on GitHub.

 

In this first post of a series, I will go over structure of the DAICOVO.

DAICOVO Source Code and Development Environment

Again, you can go to this repository below to find the source code.

 

 

 

Here are the requirements. As we have used Truffle for the development environment, directory structure follow its rule.

 

・Node v8.10.0

・Truffle v4.1.13 (core: 4.1.13)

・Solidity v0.4.24 (Truffle includes solidity compilers)

 

We won’t explain how to use these tools, but I encourage you to familiarize yourself with them. There are more than enough tutorials and documentations online.

 

Structure of DAICOVO

The DAICOVO consists of seven smart contracts. There are other contracts in our repository, but we won’t mention them here because it is outside of the DAICO model.

 

 

DaicovoStandardToken(Token)
This is a template for a token. You can set up parameters such as a token name for each project. It’s ERC20 compatible with some extensions of ERC223. However, the ERC223 part of the code is a bit different from the original interface of the ERC223.

 

TokenController
This contract is in charge of a token issuance. It is a project owner(the owner of TokenController contract) who has the authority to issue tokens before a token sale. During the sale, the TokenSaleManager contract holds that power. In the current version, no one will possess the power to issue tokens anymore after the sale. However, it will be possible to issue tokens through voting in the upcoming updates. For this reason, we’ve already written the interface that allows the Voting contract to issue tokens after the sale.

 

TimeLockPool
TimeLockPool contract locks up ETH and tokens until the given time, and allows the project owner to withdraw the funds after the given time predefined in block.timestamp. Since one TimeLockPool instance can hold various kinds of ERC20 tokens and ETH, it can be shared in many projects.

 

TokenSaleManager
TokenSaleManager contract manages a series of token sales. There are some TokenSale contracts under this contract. When ETH is sent to the TokenSalecontracts, they make the order to issue tokens to the TokenController via the TokenSaleManager contract. Once all the TokenSale contracts are over, it sends a signal to start a project to DaicoPool contract. And all the funds raised through the sales will be sent to the DaicoPool contract.

 

TokenSale
TokenSale contract is a template for a token sale. A single TokenSale contract deals with each phase of sales such as a pre-sale or a crowd sale. Furthermore, you can set up parameters such as token price, a term of a sale, the number of tokens on sale, a time lock(true or false), or a carryover(true or false).

 

DaicoPool
The DaicoPool contract pools the funds raised. Each TokenSale contract sends the funds to this pool contract once it’s finalized. When this contract receives the signal to start a project, the tap will be opened, which allows the project owner to withdraw the funds. Furthermore, this contract acts accordingly when it receives the signal to raise a tap or self-destruct the contract from the Voting contract.

 

Voting
The Voting contract. Anybody can make a proposal by sending a certain amount of ETH to this contract. There are two proposals you can make: the tap-raising and self-destruction. During a voting period, token holders can vote by depositing their tokens to this contract. If the proposal garners support from a majority, the Voting contract sends the signal to the DaicoPoolcontract.

 

 

I hope you could get a good understanding of the structure and the outline of each contract.

 

In the part 2, we will explain a deployment and operation flow of the DAICOVO. Even if you were just planning to use it as it is, it will help you to understand how to use it.

 

After the part 3, we will look into the code of each contract in detail. You will be able to understand how each function is implemented and how we came to this form of implementation through contemplation and discussion.