Our thoughts on how any fair and responsible ICO should be performed are very much in line with the DAICO model. We immediately created the first implementation of a DAICO modelled ICO contract.
To be able to implement DAICO into a real-life ICO environment, we have integrated it into our open-source framework: decentralized & responsible ICO “RICO”. RICO was developed so that developers can flexibly design various ICOs and run them completely on smart contracts.
For the specific implementation of DAICO in an ICO we have created the architecture as follows:
Currently, we support the following methods:
- 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:
How to vote
The method of voting is to deposit your 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)
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 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: Start time of 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 a new proposal
- isDestruct: Whether this proposal aims to shift to Withdraw mode (eliminating the fund)
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 token holders to extract ether.
uint refundAmount = this.balance * lockedTokenBalances[msg.sender] / token.balanceOf(this);
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 the functionality of certain discipline algorithms (e.g. Slasher, an appropriate burn model).
You can find all our DAICO and RICO related code here(daico-pod branch): https://github.com/DRI-network/RICO/tree/daico-pod
Note: This architecture may change in future.
We are waiting for your comments and contributions!