Towards Responsible Token Sales (ICOs)
Given the backlash from recent ICOs, it seems clear that as a community we need to set (and enforce) a baseline for responsible ICOs. Just like any ICO needs to (or should) use an audited ERC20 contract to be taken seriously, so should they use an “ERCXX” that implements fiscal responsibility.
Here I will lay out what I believe are important rules any project looking to crowdfund should follow, along with an analysis of their effects. Feedback welcome.
Under no circumstance should the money raised be released all at once to the development team.
We’ve seen a lot of projects lately raise 10+ million, with no real restriction as to how they should use this money beyond “trust us” declarations and vague roadmaps. I don’t think this kind of self-policing is sustainable, and why resign ourselves to this when we have the power of a consensus network at hand?
This risky proposition can be resolved as follows — have the smart contract encode “staggered” release of funds, e.g., if 10 million is raised and that’s supposed to last 4 years, release 2.5 million immediately and have the token holders vote at the end of that year to choose whether the next 2.5 million should be released or given back to the token holders (burning the tokens if gross incompetence is occurring). This gives a couple of nice properties, such as only holding the token long term if you actually care about the project and want to vote, and giving a kind of “base” valuation for the token. If the token holders acting as oracles choose to award the project with the next 2.5 million, it’s a vote of confidence for the underlying platform as it signals the token holders believe the project can generate more value if the dev team is funded, compared to the amount of Ether they would be refunded if they choose to burn the tokens.
This also keeps an implicit price floor in the token: If the price of the token ever dips below the crowdsale price over the amount of money already released, then burning the token gives you more ETH than the token would sell for.
One can prevent massive buying of the tokens right before the vote by requiring token holders to stake N months before the voting period to be eligible to vote. This prevents whales and exchanges being able to shut down projects single-handedly without risk.
This also lets the market expect how much ETH the project will reasonably sell to fund the first N months of development. Hence, people will be less likely to dump ETH right after a 100 million dollar crowdsale, as they know they’ll only be able to sell 10 million at first, for example. This “should” also increase the price stability of ETH during ICOs.
A common argument against locking funds centers on fluctuations over the value of ETH in the long term, but I don’t think that makes much sense. Assuming the Dapp makes use of the Ethereum platform, if Ether ever devaluates to the point that the crowdfunded money is not enough for the dev team to continue, then it’s likely the business model of the dapp itself will no longer be viable either way.
Plus, if the price is at an all time high, then hype and money flow is also at an all time high. So, if it wasn’t so high, it’s likely the amount raised would have been lower anyway. If the price is on the low-side when the crowdfund is taking place, then the locked funds will likely go up in value in the year. Over time the value should go up on average if all these projects are good projects that are building on ETH and increasing the value of the Ethereum platform (instead of damaging it with nonsense ICOs).
It also incentivizes the team to find independent revenue sources in the long term and pushes them to complete product milestones sooner rather than later. If the project is really any good, it should not be hard for the development team to acquire additional resources, especially after a year of serious development. Just like the Ethereum foundation has done with the foundation tip jar, which has gotten quite a bit of Ether over time: https://etherscan.io/address/0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359
Eventually this should also be a non-issue once someone creates a proper stablecoin.
Ability for investors to set personal caps on valuation
Seeing as popular ICOs nowadays are basically DoS’ing the network, many people send hundreds of transactions each hoping one will be accepted. The problem with this is that if you want a condition like, “I only want to participate if they have raised less than 10 million so far, because I don’t think the team will ever need more than that”, you can’t guarantee this condition. If you were to wait until the contract had 10 million in it, it’s likely already too late to try and buy as the tx queue is full for the next 1,000 blocks. One could write a smart contract to check this and only forward the transaction if the condition is met, but most users won’t be able to do this.
Hence, in the ICO contract there should be a parameter N that the function can accept which, if non-zero, returns the funds to the sender if the amount raised so far is greater than N.
This prevents what happened with the bancor ICO where parties assumed it would be completed within the 3 hour deadline, and it was “extended” due to “attacks” and they doubled their own valuation due to misleading terms… which brings me to the next rule.
Absolutely no changing code or terms of crowdsale during the crowdsale, or up to a week before
You could enforce this as a sort of ERC ICO contract, where all ICO contracts must inherit from this contract a rule that if the contract was deployed less than 7 days ago then the ICO cannot yet start. It’s debatable whether this is a good solution code-wise as there would certainly be ways to modify parameters after the deployment, but either way, it’s something that the community as a whole really should enforce. Anyone who breaks this should be shunned by the development community as a whole — and if your platform has no devs it’s pretty useless in this space.
Optional: Lock tokens for 1–3 months after sale
Since nowadays tokens become tradeable immediately and there’s plenty of exchanges that also list them immediately, speculators who buy the token simply to sell it immediately after the crowdsale are aplenty. This should really not be the target market of token sales (if this is your target market, please leave Ethereum and take your project with you, we don’t need you). People who fund an ICO should be ones who actually believe in it, want to see the platform built, and want to use it.
The reason I put this as optional is that is kind of creates a bad incentive: a whale or exchange going in and buying ⅓ of the crowdsale, and then creating an IOU market for the token, like what happened with Ethereum after the crowdsale. Not sure how to solve this really beyond either having value-limited buys per on-chain identity (using uPort, for example), or maybe someone can create a sybil oracle of some sort. Suggestions welcome.
Conclusion?
These are the rules that I, at least, would follow if doing a token sale. While there are many good projects building on Ethereum right now, I’m always suspicious of how the funds will be used.
Most people’s mindsets will change very drastically before and after having 10–100 million in the bank. I think releasing the funds all at once makes people lack a sense of urgency, and in some sense motivation as well. Why feel rushed if you’ve got enough runway for 10+ years? If things get hard, why even do anything at all? Just take a vacation with your millions.
Most projects in this space that have been around for 6–12 months have delivered very little considering the amount of money they raised. Consider that a company like Uber raised 11 million in their Series A, and they already had a real product people used by then (it had already been live in San Francisco for a year).
As a final point, please, everyone: do some due diligence in what you invest in. Many projects sound “great”, but they hand-wave away insanely difficult research problems that might take years to solve. I have nothing against funding research towards these problems, but I do have a problem funding a project that assumes this problem will go away on its own.
Let me know if you disagree with anything, and I’d love to see the rules formalized into some sort of ERC and enforced by the community (and exchanges).
Any feedback is more than welcome.
