In this part 5 of a series, we will cover the DaicoPool contract that manages the funds raised.   Each TokenSale contract sends the funds to the DaicoPool contract when it is finalized. Thus, all the funds raised through the token sales will be pooled in this contract, and then it starts to release the funds by following the tap amount you set up before the sale.   Here is the constructor: [crayon-64743f1598396594293608/]   You literally give the tap amount[wei/sec] to tap_amount. The project owner should give the same amount they specified in their white paper. Since the tap amount is in public, you could lose the trust from investors if you give the different value to it.   By the same token, you specify the amount of wei for your initial release for your_initialRelease. Inside the constructor, the Voting contract will be deployed and the tap amount and the self-destruction will be managed by the Voting contract.   State Transition The DaicoPool contract has three states. Initializing(before the project is in progress) The funds won’t be released yet. It receives the funds from the TokenSalecontract. ProjectInProgress(the project is in progress) The funds release depending on the tap amount. Destructed(after the self-destruction) This is the self-destructed state after the proposal of the self-destruction is passed. The funds won’t be released anymore, and token holders can get a refund.   Variables These are variables in this contract. [crayon-64743f15983a3206268111/]   The Association with the TokenSaleManager The DaicoPool contract associates itself with the TokenSaleManager with the setTokenSaleContract() function in the DaicoPool contract when the TokenSaleManager contract is deployed. This setTokenSaleContract()function cannot be executed more than once.   The TokenSaleManager will be able to trigger the release of the funds with the startProject() function.   [crayon-64743f15983a9774642388/]   Start The Release of The Funds The TokenSaleManager contract executes the startProject() function in the DaicoPool when it is finalized after the token sale. This changes the state from Initializing to ProjectInProgress, which release the initial funds and start to release the tap depending on the amount you…

I will talk about the TokenController contract in this post. The TokenController contract manages the issuance of tokens: it mints tokens as the owner of the token contract. It also serves as a controller that manages permission to mint tokens in each three phases of the token sale.   This is the constructor: [crayon-64743f1598c21492463120/]   State Transition The TokenContoller changes its state in this order below: before the token sale during the token sale after the token sale This is how the states are written in the contract: [crayon-64743f1598c2a784395750/]   Mint Permission Here is how the TokenController manages permission to mint tokens: Before the token sale, only the project owner(the owner of the TokenController contract) can mint tokens. During the token sale, only the TokenSaleManager can issue tokens. When it receives ETH from an investor, the TokenController mints tokens via the TokenSaleManager. The project owner can no longer mint tokens at this state. After the token sale, nobody can issue tokens anymore. However, in the upcoming updates, we might make it possible to issue tokens when the proposal to issue extra tokens garners support from a majority. In this case, only the Voting contract will have the permission. This permission management is implemented in the mint() function. [crayon-64743f1598c2e392970174/]   Operation Flow Here is the operation flow of the TokenController. You can check the whole operation flow in the part 2 of this series. Deploy the TokenController (state: “before the token sale”) Transfer the ownership of the token contract to the TokenController The project owner(the owner of the TokenController) distributes tokens before the token sale with TokenController.mint() function. Change the state to “during the token sale” with TokenController.openTokenSale(). The TokenSaleManager executes the token sale. Finalize the TokenSaleManager, which calls closeTokenSale() in the TokenController. The state changes to “after the token sale”.   State Transition Functions Firstly, the constructor() changes the state to Init(before the token sale). Secondly, the openTokenSale() changes the state to the TokenSale(during the token sale). Finally, the closeTokenSale() changes the state to Public(after the token sale). [crayon-64743f1598c32826220502/]   Other Getter Functions…

In part 1, we explained the structure of DAICOVO. And in part 2, we talked about the deployment and operation flow. In this part 3 of the series, we will look at the most basic contract: the token contract. Requirements of a Token We have DaicovoStandardToken contract as a template of a token contract. This contract is ERC20 compatible token with some extended features from ERC223. You can either use this template to issue tokens or use other types of tokens to start your ICOs with the DAICOVO. However, keep in mind that your token needs to meet requirements below.   ERC20 Interface [crayon-64743f1598fca384594117/] Mintable Interface [crayon-64743f1598fd2344796236/] Ownable Interface [crayon-64743f1598fd4343307565/]   In the DAICOVO, tokens are issued(minted) through the TokenController: mint(address _to, uint256 _amount) function will be called from theTokenController. As only the owner of the contract can call mint, you need to transfer the ownership to the TokenController. Structure of DaicovoStandardToken The DaicovoStandardToken is the ERC20 compatible token contract template. We also borrowed some functions from the ERC223 token standard that eliminates the problem of lost tokens. On top of that, there are other functions and variables for flexibility. They also help us to solve known issues. You can see the members of the DaicovoStandardToken contract below.   We won’t mention members in ERC20 in this post. You can find more than enough articles about this standard online. *The DaicovoStandardToken contract is based on the code from ERC20 compatible contract in OpenZeppelin and ERC223 compatible contract from Dexaran. Both of them are OSS under the MIT license. Problems with ERC20 The problem with ERC20 is that tokens will be lost forever when ERC20 tokens are transferred to a contract address. This is why we borrowed some functions from ERC223 in the DaicovoStandardToken.   When you send ERC20 tokens in your balance, you use the transfer()function. If the recipient were an EOA(Externaly Owned Account), they will know that they receive tokens because humans are…

In this part 2 of the series, we will talk about a deployment and operation flow of the DAICOVO. If you were going to use our contracts as it is, you can operate it by simply following the operation flow below.   We will cover the whole process in order: before the token sale, during the token sale, after the token sale, voting period and after the approval to the proposal. Until the Initial Token Distribution Deploy the DaicovoStandardToken contract. [crayon-64743f159949a470421580/] You may use your own ERC20 compatible token. But in that case, you need to inherit Mintable and Ownable contracts.   Register your white paper to WhitepaperVersioning contract(optional). This is optional. You don’t need to use this contract unless you want to execute your ICO on top of ICOVO platform. This contract prevents project owners from tempering with their white paper.   [crayon-64743f15994a3363054962/] WhitepaperVersioning has an instance globally. You register your white paper on this instance. To be more specific, you register the white paper itself on IPFS and add the hash to the WhitepaperVersioning contract. This way, you can trace the change history. You can update the white paper every time you execute pushWhitepaper( ).   _contract should be Ownable and only the owner can register initially. For further updates, you can register from the address you registered first. This means that the initial registrar will have the authority to update for good even if the owner of _contract change later on.   Deploy the TokenController contract. [crayon-64743f15994a7072791378/]   Transfer the ownership of the token. [crayon-64743f15994aa997747910/] You change the owner to the TokenController by executing thetransferOwnership() function. The WhitepaperVersioning should be taken care of before this process because it changes the owner. After this change, the TokenController will be in charge of issuing tokens.   Issue tokens via the TokenController contract. They can distribute the tokens that will be allocated to their team members or marketing expenses. If you were to have closed sales, you can…

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 https://github.com/icovo/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…