Topic: DAICOs ? (Read 144 times)
This would be a wonderful achievement of implemented. The rate of scam ICO Projects is really alarming. So I'm in support of DAICO but on the other hand, it actually looks like going back to the era of centralisation in form of shareholders. Hope this won't defeat the whole idea of cryptocurrency in the first place?
Vitalik Buterin, the creator of the Ethereum Network, proposed a new method for decentralized fundraising called the “DAICO”. Incorporating elements of Decentralized Autonomous Organizations, or DAOs, the new model is designed to minimize the complexity and risk associated with ICOs.
The main idea of DAICO model is to enable ICO’s to raise fund for a single project, but at the same time reduce the risk of manipulation or fraud.
The model gives investors more control over how funding is spent and a smart contract is created to ensure the project team fulfils its promise.
In January 2018 he made such an explanation:
https://themerkle.com/wp-content/uploads/d422da54d200e5dc8e119de3a65ec885a542b4c3.png
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. This can be implemented as follows:
tap: num(wei / sec)
lastWithdrawn: timestamp # Make sure to initialize this to the contribution period end time
@public
def withdraw():
send(self.owner, (block.timestamp - self.lastWithdrawn) * self.tap)
self.lastWithdrawn = block.timestamp
@private
def modify_tap(new_tap: num(wei / sec)):
self.withdraw()
self.tap = new_tap
There is also a mechanism by which the token holders can vote on resolutions. There are two types of resolutions:
Either resolution can pass by some kind of majority vote with a quorum (eg. yes - no - absent / 6 > 0). Note that lowering the tap by vote is not possible; the owner can voluntarily lower the tap, but they cannot unilaterally raise it.
The intention is that the voters start off by giving the development team a reasonable and not-too-high monthly budget, and raise it over time as the team demonstrates its ability to competently execute with its existing budget. If the voters are very unhappy with the development team’s progress, they can always vote to shut the DAICO down entirely and get their money back.
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:
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.
Variations
In easy words, what sets the DAICO model apart from the ICO model is a mechanism the authors described as a “tap”.
The function gives investors control of how much funding the project team has access to and how the money will be spent.
The protocol here basically works like a trust fund; the project team is not permitted access to money without the authorisation of token holders.
The team has to put in a justifiable request stating how much funding they need and what the funds will be used for.
For example, say the team need to install another server in order to make the blockchain quicker and more reliable. The ICO will request a raise in the “tap” value and investors vote on whether the team should be granted the funding.
However, the purpose of the tap is to provide the development team with a budget they need to complete their goals, but at the same time give investors the opportunity to agree to the idea, protect their investment and to ensure that goals are met.
When the core team hits their targets, the amount of the tap can be raised so the team can grow. Therefore the DAICO model can help ICO’s plan their strategy and have the incentive to meet deadlines.
The example of such model may be https://www.theabyss.com, but i cannot be sure yet if it is really prooved DAICO, i don't have enough skills.
The main idea of DAICO model is to enable ICO’s to raise fund for a single project, but at the same time reduce the risk of manipulation or fraud.
The model gives investors more control over how funding is spent and a smart contract is created to ensure the project team fulfils its promise.
In January 2018 he made such an explanation:
https://themerkle.com/wp-content/uploads/d422da54d200e5dc8e119de3a65ec885a542b4c3.png
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. This can be implemented as follows:
tap: num(wei / sec)
lastWithdrawn: timestamp # Make sure to initialize this to the contribution period end time
@public
def withdraw():
send(self.owner, (block.timestamp - self.lastWithdrawn) * self.tap)
self.lastWithdrawn = block.timestamp
@private
def modify_tap(new_tap: num(wei / sec)):
self.withdraw()
self.tap = new_tap
There is also a mechanism by which the token holders can vote on resolutions. There are two types of resolutions:
- Raising the tap
- Permanently self-destructing the contract (or, more precisely, putting the contract into withdraw mode where all remaining ETH can be proportionately withdrawn by the token holders)
Either resolution can pass by some kind of majority vote with a quorum (eg. yes - no - absent / 6 > 0). Note that lowering the tap by vote is not possible; the owner can voluntarily lower the tap, but they cannot unilaterally raise it.
The intention is that the voters start off by giving the development team a reasonable and not-too-high monthly budget, and raise it over time as the team demonstrates its ability to competently execute with its existing budget. If the voters are very unhappy with the development team’s progress, they can always vote to shut the DAICO down entirely and get their money back.
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.
Variations
- Denominate the tap in usd / sec, and use some price feed
- Experiment with mechanisms other than simple voting
- Use DAI as the funding currency instead of ETH
In easy words, what sets the DAICO model apart from the ICO model is a mechanism the authors described as a “tap”.
The function gives investors control of how much funding the project team has access to and how the money will be spent.
The protocol here basically works like a trust fund; the project team is not permitted access to money without the authorisation of token holders.
The team has to put in a justifiable request stating how much funding they need and what the funds will be used for.
For example, say the team need to install another server in order to make the blockchain quicker and more reliable. The ICO will request a raise in the “tap” value and investors vote on whether the team should be granted the funding.
However, the purpose of the tap is to provide the development team with a budget they need to complete their goals, but at the same time give investors the opportunity to agree to the idea, protect their investment and to ensure that goals are met.
When the core team hits their targets, the amount of the tap can be raised so the team can grow. Therefore the DAICO model can help ICO’s plan their strategy and have the incentive to meet deadlines.
The example of such model may be https://www.theabyss.com, but i cannot be sure yet if it is really prooved DAICO, i don't have enough skills.
What are DAICOs, any example of DAICO and how are they different from ICOs ?
Jump to: