I do agree with you about that, however, since lots of ICOs gets just a little attention I do think they are still vulnerable to price manipulations which might cause this. I am not sure about a solution for that (or if a solution is really needed) but I do think there should be a mechanism to protect ICO teams from malicious manipulations. I think there should be at least an initial time period before it’s possible to vote on self-destruct, if the team does a bad job no one will increase the tap anyway. This can help the team work on the project without worrying about someone shutting it down until the market gets a bit bigger and harder to manipulate.
Also I think there should be an option for the team to request a one-time large withdrawal for a specific usage (let’s say a big marketing campaign which is required to be paid upfront). If they do buy lambos with it the project will be shut down (and someone will probably sue the team), but as long as the team is honest this can help the project grow faster.
Hi guys. I am categorising ICO models in this doc -
I’ve already added the DAICO to the list.
Feel free to add your comments and help me!
Your feedback will be highly appreciated.
@vbuterin So voters can’t influence on developers decisions? It’s sort of “wishes” from token holders?
Then there’s the second line of defense: if something that is clearly an attack takes place which causes all funds to be returned, then the DAICO devs can just make another ICO.
Another thing to consider is maybe letting each contributor set the tap-rate of their own contribution. That way, project owners gain little by contributing to their own project (perhaps they still gain positive feedback of having more apparent investors). On the down-side I don’t know if there is an easy way to code this.
This is a logical step in ICO evolution. We’ve implemented a similar idea of ICO DAO-fund where investors vote for each money transfer to the project and as an option could delegate their vote to other investor. The difference is that we’re using a series of predefined transfers instead of the tap.
The prototype code is here (consider it alpha): https://github.com/mixbytes/ico-fund-prototype
I like the tap mechanism, but I think the value stems from not releasing funds to projects in a lump sump all at once. That way investors can keep founders accountable throughout the development lifecycle. There a lots of ways that can be achieved other than the tap mechanism that might work just as well.
I proposed a similar mechanism for the 1Hive project that uses a continuous token model where newly minted tokens fund a reserve, and investors can exit by pulling out their pro-rata share at any time. Funds in the reserve move into the projects discretionary fund over time, very similar to how the tap mechanism works. Discussion about 1Hive can be found here.
Another approach to minimize investor risk in ICOs would be to use something like Giveth’s Liquid Pledging to enable founders to raise funds incrementally based on milestones. This process combines with some governance over new token minting would emulate the more typical startup funding process where founders have to convince their existing investors that they should dilute shares as well as show progress in order to unlock further funding.
Unfortunately, none of these solutions will work in a market where investors are willing to buy $TRX. But perhaps by ensuring these options are readily available and making investors aware they will start to demand more accountability from projects… ¯_(ツ)_/¯
This is exactly what we are working on at coincrowd.it a platform that generate DAICO we was not using this term but we will. To solve problem of bad investors that use 51% attack to withdraw ETH from a team doing good job we think to give the team a kind of “Appeal Court” using a new vote with third part like Aragon or similar DAO. And we are not using the “tap” way but will think about it.
Any way we felt the ICO place is like a far west and need some rules. Not only from government but directly also from DAO. This si the reason why we start building coincrowd.it and in this day we are releasing a first version of coincrowd wallet a mobile app that make very easy take part to ICO even for who is joining for the first time. This is another experience we get from consultantcy for other in ICOs some new project that decide to run an ICO today have a strong community, but this community often is outside of crypto, and to partecipate in ICO for them is very hard. With coincrowd wallet we reduce the effort. in version 1 user must have ether in version 2 user can have ether directly from the app.
Hi start to collaborate to the paper 
We solved the problems with the trust of participants in their smart contract for ICO, we realized a refund on request. That is, if there is a mistrust of the project - you can return the tokens back to the address of the contract and launch a refund in the private office of the platform throughout the period of the Pre-ICO and ICO. For this we used:
- the price of the token = 0.25 USD, when the tokens are issued, the contract refers to the oracle, which sets the value of the invested funds by the median of the exchange rate of 5 exchanges
- We removed the boundaries of Soft Cap and Hard Cap, the project costs as much as the community estimates it.
- Payment and refund by other crypto-currencies
My Vision:
- Realize monitoring the cost of the Oracle tokens to allow voting at a low threshold of the cost of the tokens
- Add a function to reduce the maximum charges when the value of tokens on the exchanges decreases
- To freeze tokens for 7-14 days after each move of tokens to other purse addresses, to reduce the possibility of pumps or dumps
Link to github
I love the simplicity of it. My only alteration would be to replace the voting on shutdown with an option to cash out your token at any point. So if the fund raised 100 ether and sold 100 tokens then at the start, tokens can be redeemed for 1 ether. As the DAO spends ether from the tap, the redeem rate falls. This way people can individually secede without the need for democratic shutdown. You can then measure displeasure by the rate of liquidation rather than it being a sudden event.
As someone that is on the early startup stage and has been looking at the multiple funding options available (Bootstrap, ICO, Seed round etc), this seems great way to set it up in a responsible way as well putting a fair amount of control on the investors side.
Also depending on how the voting system gets implemented, this really incentivizes the developer team to be as transparent as possible, and keep the channels of communications with investors open.
One thing that does required further discussion is a mechanism for controlling the distribution of tokens from the get go, to guarantee that the development team doesn’t hold a high percentage of the original token supply and easily sway the votes.
The other promising thing that I see on this model is that while the DAICO proposal only focuses on the funding aspect, the same concept/contract could be expanded to other aspects of the organization governance.
I think that diaco is just an example of such voting system that you mean. But currently It’s not possible to create flexible structure with Ethereum without extra cost. I’m trying to implement enterprise-alike resource management with contracts to allow companies own any type of tokens. But each new type of resource need to recompilation of all other contracts and new allocations which is very expensive.
@vbuterin What do you think about implementation of interfaces like in golang to allow some contracts to manage any interface implementation. For example we can create management contracts which can own every contract with methods isOwnedBy, isOwn and transfer. It will allow to accumulate resources within one contract without address changes and extra memory allocations. Or to make possible to pass functions as arguments.
Here it’s proposal for EIP-829.
Who the hell am I
Hello world: First an intro. Hi all, I run a company in HK and Shenzhen (@vbuterin saw you speak a few months back, your Chinese is awesome, good job there!) that would consider raising in this fashion as an alternative to conventional investment. Because I have been approaching this point with my real world company I have been reading up a little bit on Private Equity (PE) deals and happen to have a meeting with one of the world’s most respected international law firms in the space on Monday in Hong Kong specifically to discuss alternate models of financing, so may be made aware of some other options shortly. I have a history of working in the crypto space … which is why after seeing an HN post on this thread I was therefore motivated to join here and contribute to the discussion - I can potentially provide a serious, real world, high visibility guinea pig deployment of this concept to a legitimate business in 9-12 months if it is adequately developed.
INVESTMENT TRANCHES
Concern: In the conventional finance world I am aware of one clear funding strategy which is used to institute control over companies which is investment tranches. This basically locks partial funds release until some kind of milestone has been achieved, for example an external audit completed or a certain business objective reached. Usually there are multiple tranches, and they are agreed ahead of time. However, there is also scope for discussion and movement. AFAIK you see this kind of approach used in all sorts of investment scenarios, from the mundane (home loan / mortgage scenario where investors manage risk throughout a construction project by requiring certain physical construction goals to be complete before the release of additional funds) to the exotic (large corporate deals). Note that in many cases, it is the nature of a project that certain tranches (large spending requirements) can be known and justified ahead of time, though actual execution tends to track less predictable project advancement rather than nominally agreed upon fixed schedules. The current proposal’s tap (rate-based) rather than event/tranche (chunk-based) design ignores this reality and makes it impossible to acquire a tranch without exotic workarounds (set high tap release rate, reset to low tap release rate).
Counter-proposal: I would therefore propose a revised design which perhaps allows a mix of:
- The current design
- A tranche-style release
- A combination thereof
- Some kind of subsequent ad-hoc tranche-style release to be voted on (fixed amount released)
TWO WAY GUARANTEES
Concern: Note also that in many scenarios the digital contract should be protecting the interests of the recipient, not just the new investors. For example, the recipient may also be invested in the outcome and may also be at great risk. The capacity of the current design to be effectively blocked over time (tranche never appears) is a huge risk for the recipient, who may manage their business under the expectation of timely funds release. Therefore I would suggest that some form of recovery scenario should be possible whereby a third party (eg. a set of three paid dispute arbitrators) can be appointed and gifted with keys to enable partial or complete control of funds in the event that it is required. While this goes against the “freedom loving crypto paradise” meme, it is very much a “real world businesses would prefer it” kind of reality.
Counter-proposal: Add a percentage of funds (usually 100%) that can be released or controlled by the agreement of multiple arbitrators (n of m) in the event that their involvement is triggered either by the investors or the recipient. Note that the arbitrators should be actual real world legal arbitrators with reputations to uphold and there should be an enforced arbitration period (eg. 7 days), with non-participating arbitrators increasing the arbitration period by a small factor, and a minimum number of participating arbitrators, so as to avoid “appoint thousands of arbitrators and fail to garner participation” issues or “kill the arbitrators to affect the outcome” type attacks. If arbitrators totally fail to check in (or lose their keys), funds could also be auto-released somewhere (eg. to a charity).
CONVERTIBLE DEBT
Concern: Another major means of structuring investments in order to influence the behavior of recipients is convertible debt. Convertible debt is basically a loan with the regular strings attached (interest payments, compounding, etc.) but also clauses allowing the loan to be converted to equity in the recipient’s organization under certain conditions. For example, this may auto-trigger if payments fail to be made, allowing the investor to obtain a large percentage of the recipient organization at a discount rate. It may also normally be subject to buyback (recipient can purchase away these rights by paying back the loan) or other specific clauses (if company goes public, rights to convert to equity at a preferable rate are guaranteed).
Counter-proposal: None. Unsure whether such a structure could fly in ETH-land.
FIAT BASELINE
Concern: In our real world business case projected expenses need to be denominated in fiat currencies. However, we do not necessarily want to do an uncapped ICO-style raise and take heaps more money than we need for a fixed supply of tokens, rather do a capped raise. The issue with a capped raise is that by the time the expenses roll around (projected tranches) ETH’s value may have moved significantly.
Counter-proposal: Allow the entity raising funds to embed some sort of plan, exchange rate projection, or other information (arbitrary document checksum and magnet URL?) with the raise in order to explain the assumptions around which the project is based. Therefore, if the fiat economy goes off a cliff (ha!) or exchange rates vary tremendously (quite frequent swings of up to 30% even amongst major currencies are the norm) then all parties are clear on how this will be mitigated or otherwise impact execution. Failing this, some set of one or more ‘fail to arbitration’ or ‘fail to re-raise event’ options could be hardcoded as options with specific terms that investors agree to up front.
PAYING THE ARBITRATORS
Concern: Nobody works for free, and the auditor option (cynically “fetch a grown up” button), when pressed, needs to grab someone with enough ‘skin in the game’ (reputationally and legally) that they are adequately disincentivized from malpractice. This costs money.
Counter-proposal: Tranche release or fund lifetime should have the capacity to include staged arbitration payments. Most lawyers and arbitrators will want to put in work up front (client due dilligence) so will require up-front payment. Ongoing payment (tap-style) would be ideal as a sort of annual drip for them, to keep them breathing. Finally, a per-incident payment (eg. serious arbitration case requiring actual research and time investment, suddenly activated mid-holidays with a 7-day limit) should be reasonably enough compensated as to make it worth their while to do a good job. Larger firms will have people not on holiday, and will cost more. You get what you pay for, to a certain extent.
IDLE FUNDS
Concern: In a traditional investment context, there is a very common configuration in which funds are nominally committed to an investment vehicle however they are not actually transferred until a ‘call-down’ is received. This is a notification that the funds are required, and they are contractually obligated to arrive within a certain time. This is apparently the most common Venture Capital fund configuration. The benefit of that configuration is that funds can be earning interest or otherwise managed against risk until required. In the configuration being proposed, funds are locked until released, which is sub-optimal.
Counter-proposal: Consider allowing a call-down. This could be viewed as effectively as a form of reverse-tranching affecting the investor rather than the recipient. Taking that parallel further, the tap concept could also be applied here. Alternatively, acquiring all funds up front then defining a strategy for and allowing funds management (by some entity, automatic or appointed) prior to tranch-based calldown over the course of a fund could be implemented.
what if the dev team place buy orders that are a bit higher then the refund price in order to gain 51% ?
Thoughts here are sound. However, does not highlight the flaws of these are they have been tested over the past two decades in the current fraudulent system.
Aim is to borrow what simplifies AND strengthens.
-Richie Etwaru
This certainly reduces the fraud stemming from “Lambo ICOs”. I’m not sure why 51% is the magic number, well strike that - I get that we want a democratic voting process, but even in the best democracies some things are better decided with 60%, or 75% votes.
The majority’s opinion does not mean its the best/right one. Can we strengthen a mechanism of elastic majority? where we start at 51%, but based on some elements of the venture, majority can be redefined.
Regards,
-Richie Etwaru
The majority is almost never right unless there is a mechanism for punishing those who are wrong and rewarding those who are right and that mechanism is applied over time and future votes are weighted based on history of reward/punishment (which actually means it is no longer a “majority” based vote).
This is where/why identity, and reputation of human nodes need to be on-chain. While nodes with good reputations can flip, and take bad actions - we can lower fraud a bit more if the investors and programmers longitudinal identity and reputation are onchain.
-[RE]
Great idea. But ICO still need auditing service to be more reliable. I would like to create a ICO auditing company for ICO which will audit from team, code, PR campaign to what they have done according to roadmap.