A few days ago, DAICO was announced by Ethereum co-founder Vitalik Buterin. The vision proposed by DAICO shows the future of ICOs. Also, it has many points in common with RICO, the open-source ICO framework we develop. RICO was developed so that developers can flexibly design various ICOs and run them completely on smart contracts.
We have integrated support for the DAICO model in our RICO framework. This is also one of the first (if not the very first :) implementation to be made with the DAICO model. The code can already be seen on Github.
Note: This code is currently under development and may contain bugs.
Mr. Vitalik’s post is an idea but no actual implementation examples are given. Therefore, we have added our own interpretation to implement DAICO. For the specific implementation we have created the architecture as follows:
Contribution mode
In DAICO, the donation period in ICO is called Contribution mode. RICO already supports the following methods to do the Contribution modes:
・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
DAICO creates discipline for the development team of the project after completion of the ICO through an ongoing voting process of the project’s supporters. The method of voting is for the supporters to deposit their 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)
With the DAICO model a vote can be proposed to do either one of the following two actions:
- Increase the “tap” amount (Tap, unit: wei / sec) that the development team can retrieve from the contract in a certain period. (basically the development team’s income)
- Move to Withdraw mode after which the supporters can withdraw the ETH left in the ICO contract. (destruction of the contract and ICO)
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 the ICO is 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: time to start 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 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 the supporters to extract ETH.
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 functionality of certain discipline algorithms (e.g. Slasher, an appropriate burn model).
You can find all our DAICO and RICO related code here: https://github.com/DRI-network/RICO/tree/daico-pod
Note: This architecture may change in future.
Questions and discussions about RICO and DAICO are accepted as Github issues and at the DRI Community Slack. Slack can participated by anyone. We would love to hear your opinions! → https://dri-slack.now.sh/
We are waiting for your comments and contributions!
About DRI
Decentralizedtech Research Institute (“DRI”) is the Tokyo community to research and develop ethereum based technologies. mail: info@dri.network
website: https://dri.network/
