KISS — Keep ICOs Simple, Stupid
KISS is an acronym for “Keep it simple, stupid” as a design principle noted by the US Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
This principle should be used for ICOs (Initial Coin Offerings). I applaud the efforts of innovators that try to adapt and improve upon previous forms, but more often than not it creates unnecessary issues.
FOMO
The crypto space is extremely difficult to predict and the Fear Of Missing Out displayed by investors leads to unexpected and very surprising results. Founders capitalize on this mindset.
Many ICOs sell out in minutes. A potential investor could miss out on one of these opportunities simply by going to the washroom or taking a phone call at the wrong time. Alternatively, even those who diligently try to invest could miss out by having their transactions unconfirmed by the network due to a drastic increase in transactions at ICO launch.
Aside from wanting to invest in the next Google or Uber, the main reason for this FOMO and craze to invest in ICOs as soon as possible is because of bonuses (bad) and caps (good).
BONUSES
When bonuses are structured based on the total amount invested, users may submit their transaction under the assumption they will achieve a 50% bonus, only to find out by the time the transaction is confirmed, the bonus has disappeared. This creates unnecessary uncertainty and a rush by all investors to obtain the greatest bonus.
If bonuses are structured based on short time periods, it also leads to a drastic increase in transactions to achieve that bonus.
FirstBlood did a Power Hour where 170 1ST tokens were received per ETH during the first hour of the sale. Following the first hour, this was to drop to 150 per, and continue to drop in the following weeks.
Naturally, savvy investors want to achieve the maximum bonus. This structure resulted in the $5.5M cap being hit in the first 10 minutes, ending the sale. It also left a number of investors unsuccessful as the blocks were too full to include their transactions.
I am not against bonuses in principle, but short-time period or cumulative amount bonuses should be avoided. Daily or weekly bonus structures are superior, and the greatest bonus should not be more than 20%.
A lack of bonuses doesn’t mean the sale won’t end quickly, but at least early investors will all get in at the same rate. In the TokenCard sale, investors who were mere seconds apart from each other received different bonus rates.
CAPS
The DAO is the classic example of a no cap situation. It raised $162 million, or roughly 14% of all ether. Shortly after the DAO creation period, the smart contract was hacked and 3.6 million ether was stolen, the equivalent of $60 million USD. Ultimately, the community decided to hard fork to regain the stolen funds.
The lack of cap creates a very strong incentive for a hacker or group of hackers to try to game the system for a great return. Overall, it was a good lesson for the ethereum community and I do not expect hard forks to occur again in similar situations.
Perhaps equally important to limiting hacking benefits, a cap is beneficial to limit founders’ greed. Founding teams run ICOs to gain funds to develop the project they are working on. Generally, founding teams retain around 20% of the tokens (or 95% for Gnosis). In my opinion, $10 million should be more than enough to cover salaries, legal, marketing and other expenses for the foreseeable future. It is helpful when teams identify what the funds are for and provide a breakdown.
No cap, very high caps, or alternative ICO structures create unwanted results, especially in a space with unsavvy investors with a high amount of FOMO.
CROSS-CHAIN CAPS
Blockchain Capital (BCAP) recently did a crowdsale with a $10 million cap. It accepted Fiat, BTC and ETH. Over $7 million was pre-invested with fiat, leaving less than $3 million cap space for crypto investors. Bitcoin transactions required 6 confirmations before being accepted. On average, it should take 1 hour for 6 bitcoin confirmations to occur. It was unclear if BCAP intended to credit bitcoin investors at the time the transaction was sent or after the 6 confirmations occurred. It was reasonable to think that sending ETH would provide a greater chance of getting in before the cap was hit.
Unfortunately for aspiring ETH senders, the website or ETH address generator was overloaded and it was not providing ETH addresses to send the transfer to. I am aware of people that tried upwards of 20 times to generate an ETH address before giving up and resorting to bitcoin, all the while being unsure if their transaction would beat the cap before 6 confirmations were made.
Due to the ability to send transactions over multiple blockchains, the BCAP offering ended up oversubscribed. I think they tried to make the crypto investors whole, while cutting back some of the fiat investors amounts. It has never really been made clear how they achieved this.
BCAP set a rate of 100 tokens per $1 USD. Unfortunately for crypto investors, it never set a corresponding rate of USD/ETH or USD/BTC, leaving investors uncertain of what rate they would receive. I am told the conversion rate for both ETH and BTC were well below the daily price that day.
BUGS
The May 2nd ICO for TokenCard allowed users to invest with ETH, REP, DGD, GNT, MLN, SWT, MKR, SNGLS, and Unicorns (easter egg!).
Unfortunately the added complexity of accepting multiple tokens increases the chances of a bug. Lo and behold, a bug occurred. Monolith Studio, the founders of TokenCard, has acknowledged this bug and is working to fix it.
The Smart Contract code should be made available to the public prior to the sale. This will help prevent any possible bugs.
MULTIPLE TOKENS
If a platform wants to accept multiple crypto-tokens, it should set an individual cap for each token. Together, these should create the max cap. TokenCard set caps for each token, but only set The Creation Event to end immediately if at any point a total amount of $12,500,000 in ETH is contributed.
The sale was set to end 24 hours after the $4.5 million ETH cap was hit, or immediately after $12.5 million in ETH was contributed.
The upper cap was hit and left some with other token transfers in limbo and uncertainty. I think it would be interesting to set the ICO to end after the cap for each individual token is reached. Rather than racing to be one of the first to send ETH, users may feel they have a better chance with MKR or GNT instead.
TokenCard also allowed investment with BTC and Fiat through BitcoinSuisse, but it’s unclear how that factored in to the overall sale. A separate cap for Fiat, BTC, ETH + tokens would alleviate any uncertainty.
In terms of ERC-20 tokens, I think the added complexity caused by accepting them is unnecessary. It’s a cute feature, but anyone that holds ERC-20 tokens very likely has a decent understanding of how the ethereum blockchain works. Rather than sending a token of their choosing, these investors could convert their tokens to ETH prior to the sale.
STRUCTURE
Gnosis decided to implement a modified Dutch Auction structure. A total of 10 million GNO tokens were created, and a sale cap of $12.5 million. The ICO sale price commenced at $30/GNO, and would decline in the coming days.
Well, rather than declining, the $12.5 million cap was reached within 15 minutes. At $30/GNO, this means 12,500,000 / 30 = 416,666.67 GNO tokens were distributed to investors. Of 10,000,000 total tokens created, the investors only ended up with 4.16%. The Gnosis team retains the remaining 9,583,333.33 tokens.
Of all crowdsales I’ve seen to date, this was the most surprising and unexpected. I think the ICO structure confused most investors and they were happy to throw money at the project because they did not want to miss out. It’s possible I am wrong about Gnosis and it will provide great returns for those who invested (it has tripled since ICO!), and of course the founders who raised $12.5 million and still control 95.8% of the tokens.
PRIOR DISPLAY OF ICO ETH ADDRESS
This is a double-edged sword. Making the ETH address visible prior to the sale prevents scams and also prevents increased web activity causing the page failing to not load to show the address. ICO websites tend to be overloaded and crash at launch time. See BCAP above.
The issue with this situation is rather than publishing an address to commence the sale at a certain time, the sale would need to commence based on a certain ethereum block number. This format gives those with added technical know-how a slight edge over the general public that simply wants to invest in “the next great thing”. Smart contracts can be created to send a transaction on a certain block. I believe this is relatively easy to set up with Parity.
I still prefer the latter over the former. In the first instance, the address contribution address is already known by a select few. It’s not published on the website yet, but it will be at Noon, or whenever the launch is set to start.
If there are bonuses available, this address can be shared to a select few who will then be able to send their transactions before the general public is able to access the address from the overloaded website. The greater transparency of a pre-published destination address should help eliminate any foul play or conspiracy theories.
TRANSFER TOKENS IMMEDIATELY UPON ETH RECEIPT
The smart contract should be simple. It receives ETH, it returns tokens at the pre-determined rate. It should happen instantly. This lets the investor know they were successful.
However, once tokens are in the investors’ possession, there should be a brief (max 1 week) non-transferable period. This allows founders to sort out any possible bugs before people trade these tokens on the open market. If a bug is discovered, it can be remedied and proper token amounts can be re-deployed on a new contract. I expect this to happen with TokenCard following it’s ICO bug. Edit: See this link: http://vessenes.com/tokencard-tech-roundup-and-erc20-crediting/
Receiving tokens instantly allows the investor to mitigate against ETH fluctuation risks. If an investor needs to wait a long period to receive the tokens, a change in ETH price can drastically change the relative USD value invested.
The main issue with this feature is that even though there are multiple warnings not to, unsavvy investors are still sending ETH to the ICO contract from exchanges. This results in the tokens being sent to the exchange wallet, rather than to the investor.
To my knowledge, reputable exchanges will make the investor whole. This should be a discussion between the investor and the exchange itself. If the ICO address is provided prior to the sale, exchanges can also opt to blacklist this as a possible withdrawal address which would mitigate the issue entirely.
Of course, for non-ethereum tokens, such as Cosmos and QTUM, investors will have to wait until that platform is developed before they will get a return.
SIMPLE IDEAL CROWDSALE
- Have a cap of no more than $10 million.
- Rather than setting the cap in $, set the cap in ETH. Eg. 125,000 ETH.
- Only accept ETH.
- Display the funding address at least a few hours prior to the sale.
- Upon receipt of ETH, transfer the tokens immediately to the sending address. A brief non-transferable period following distribution is recommended.
- Once the ETH cap is reached, no more transactions are accepted.
That’s it. Very easy.
