Safe ICO Practices (SIP)

Repost of article written by : William Mougayar

“Safe ICO Practices” or SIP

It is my belief that we can avoid excessively risky (and certainly damaging) repercussions in ICOs (aka Token Generation or Distribution Events) if the industry adopts a minimum level of self-administered precautionary practices that I’m labelling “Safe ICO Practices” or SIP.

The SEC has already shown they understand ICOs and DAOs (via their recently published Investor Bulletin: Initial Coin Offerings, and while they did not signal a desire to crush the cryptocurrency creation activities, they didn’t either telegraph a carte blanche memo pertaining to its future evolution. Other regulators such as the Canadian Securities Administrators issued more stern and obfuscated statements, such as this recent Staff Notice on Cryptocurrency Offerings.

There is no doubt that greed excesses and bad practices are regularly taking place amongst some of the new ICOs. A build-up of frequency around risky practices would certainly make it more difficult to sustain the orderly progressive growth of this new asset class. From a market evolution perspective, it would certainly be more desirable to proceed with a majority of good ICOs vs. bad ones.

With that background in mind, I’d like to draw attention on a set of practices that, if practiced together, would tilt the balance towards the “good” part more than the “bad” side.

Having been associated with, analyzed or interacted with dozens of ICOs since 2014, the following represents my best attempt at summarizing what I believe are Safe ICO Practices. These do not represent everything about an ICO, but they include areas that I wanted to comment on, because of certain common weaknesses that I see repeating themselves.

In a nutshell, there are four commonly emerging areas where a lot of the risk can build-up:

  • 1) The amount of disclosure about the token creation event (the sale itself)
  • 2) Decisions around the terms structure of these offerings
  • 3) The ongoing level of credible transparency about the evolution of the project, post-sale
  • 4) Too much speculative activity in the public exchanges prior to going live, causing a disconnect between value and valuation

Note that the following set of thoughts are not regulatory prescriptions. They are suggested practices, that once properly implemented could help to avoid unnecessary regulation. At least, they could contribute to promoting a more healthy self-discipline by ICO practitioners.

Part I – PRE-SALE READINESS
The Legal Side

An omnipresent consideration in token generation events is how the legal side jives with the business aspect. The emergent dichotomy is that one could construct a 100% legally compliant and check-marked process, while still be going after a bad business idea; or not execute well, and still fail. Alternatively, one could have a brilliant idea, with the right team, but not structure a token sale or organization properly, leaving the field open to potential regulatory risks and traps, along the way.

While business success is only realized and sustained with the passage of time and effort, properly constructing the legal aspect can and should be done right from the beginning. However, that beginning is immediately after specifying your token functionality with the utmost level of detail possible, describing the user scenarios, and not just via short or general headings like “rights management” or “self-upgrading”.

  • Good practice: Design the token functionality, then flush out the legal implications.
    Bad practice: Retrofitting token functionality based on legal limitations. Vague, or nonspecific token functionality descriptions.
  • Really Bad practice: Not linking the specifics of the token functionality into the legal aspects and implications.

Token Functionality

I’ve described a full set of token functionality in this post, Tokenomics – A Business Guide to Token Usage, Utility and Value. The token functionality is a foundational aspect and the starting point for the legal conversation that you will have with your lawyers. In summary, there are four general categories of token functionality: 1) a right, 2) a reward, 3) an ownership, 4) a toll.

The more native and organic the utility of the token is to your model, protocol, application, platform or service, the less chances of it being regarded as a security, hence triggering more potential scrutiny from regulators pertaining to existing securities regulation (which is typically well defined in all most countries).

As a global phenomenon, token sales are exposing the strengths and weaknesses of the various local or regional jurisdictions. However, an ICO is not like a website that is instantly global once a URL is published. There are local characteristics to be aware of. Since the legal field is not homogenised on a global basis, you need to take into account the local jurisdictional aspects as they will pertain to your crowd target. For example, residents of a specific country (or state) may not be allowed to participate in your crowdsale, if the local authorities have issued weak guidance in favor of ICOs, or explicitly warned against token sales.

Unfortunately, most regulators have not yet come to grips with the reality that tokens are bound to be recognized as a new asset class with its own set of updated regulation. Instead, many regulators are quick to apply existing compliance practices that treat tokens as a security, therefore elevating the barriers and costs of implementation for entrepreneurs.

We should watch for the anticipated Blockchain Cryptocurrency Property standards that Swiss-based law firm MME has been working on. It is expected to represent a set of asset class classifications for tokens that is meant to clarify their regulatory implications according to a more modern way of thinking.

  • Good practice: Keep validating your token functionality assumptions with specific usage metrics, and expect to iterate on your token functionality.
  • Bad practice: Assume that your token utility will work in practice exactly as depicted in your theoretical assumptions, or in your white paper.

Technology Audits

This includes the actual auditing of the software code to check the technical soundness of the smart contracts that are being deployed for managing the token generation, funds intake and bootstrapping the token into the App or Protocol. This is an important part because smart contracts are easily the weakest link in the ICO process, and their failing could be detrimental, if not harmful to the project. Another part that benefits from professional audits is the actual security procedures that are put in place, whether these include implementing multi-sig procedures, storage of funds, lock-up periods, rate of new tokens creation, or any other token related decisions that must be encoded for automated execution. This is an example of a technology audit for Kik’s Kin Token, conducted by Zeppelin.

Foundation Organizational Structure

Contrary to popular perception, a Foundation is not always necessary, and certainly not a Swiss-based one, even if that was Ethereum’s path. Every ICO situation is different, and organizations that opt for a Foundation should make sure they fully understand the long term implications, benefits and limitations of that choice, especially that if it cannot be later undone. Furthermore, the role and regulation around the definition of “foundations” differ from country to country.

Another aspect is the actual overlap between the Foundation and the organization building the technology. One arrangement is to let funds flow to a Foundation (or nonprofit organization) who then funds developers and other contributors like contractors. In other cases, the company receives the funds, and locks-up a part of them until a Foundation is created at a later time. Finally, when the Foundation is setup, it is more advisable to staff its board with independent members, and not entirely from the same people who were leading the ICO.

  • Good practice: Include credible people in your Foundation.
  • Bad practice: Forming a Foundation too early.

Team and Resources Identification

For small teams, include all names and LinkedIn profiles. For larger companies, management and advisors should be identified. Also, do list all existing online communities and sites that are either discussing or publishing related information to your ICO (e.g. Slack, GitHub, Subreddits, Steemit, etc.)

Token Distribution

There are no right or wrong token distribution ratios, but how you end-up dividing the pie says a lot about your intents. For example, if you are only selling 10% of your tokens and keeping 60%, you are signaling a key role for the Foundation, or your central monetary policy. However, if you are selling over 50% of your tokens, and keeping only 15% to a Foundation, then you are assuming that the community and users will take care of your evolution, and you may risk being short on dry powder for influencing your future evolution in case you need more time to deliver stable decentralization, unless your token rises in value quickly and remains that way.

A part that is not always clear, and that should be disclosed relates to the lock-up periods for tokens. Ideally, it is important to communicate exactly when large amounts of tokens become unlocked, and therefore available in public exchanges. It is a good practice to continuously update these exchanges with the right amount of tokens in circulation.

Marketing and Promotion

I’ve written previously about the role of advisors in promoting your ICOs, as one of the 10 Things I Don’t Like about ICOs. Although securing advisors support adds credibility to your projects, too many advisors will dilute that effect, as it may signal that you are erring on the side of quantity vs. quality. In addition, while these advisors may be useful to your ICO launch, not all of them will offer value (nor have the required experience) beyond the ICO process. as your roll-out your product and enter the market. To evolve and grow into the market, companies need experienced mentors, not promotional advisors.

  • Bad practice: Too much promotion and advertising. Statements that are forward-looking without concrete base of evidence or metrics.
  • Good practice: Organic spread of awareness about your ICO, backed by evidence of community and ecosystem support.

Part II – SALE

A few points to keep in mind:

  • Clearly communicate the sale process and make it very unambiguous.
  • A capped sale is more advisable than a non-capped one, unless the company already has an existing network of users where they can justify a potentially large raise that is commensurate to their footprint. A large cap in a new company with no market-ready product is risky (e.g. Tezos).
  • A large cap is considering anything over $50M.
  • Keep it clean with no PR announcements hours prior or during the sale, announcing new advisors or investors (e.g. Bancor).
  • Avoid exotic sales schemes like Dutch auctions or reverse Dutch auctions (e.g. Gnosis) or too many discount layers.
  • The trend is towards more simplicity. There is no reason why crowdsale terms should be complicated.
  • Clearly indicate the Private Sale (pre-sale) vs. Crowdsale aspects, and the difference in timing and pricing for each.

  • Bad practice: Make it complicated.
  • Good practice: Keep it simple.

Part III – POST-SALE

Now you’re just like a startup. You have to deliver what you promised, whether it is to integrate a new token into an existing platform, or to run a new network that utilizes the token.

More Audits

Independent post-sale audit of smart contract and fund disbursements. Did the company do what they intended on doing? Did they fail somewhere? Were the terms or smart contracts modified along the way, for any reason? Were the funds received and stored properly? Were ICO service providers paid accordingly, along with advisors and other contributors? Are the lock-up periods in effect?

End of Sale Report

Within 48 hours of the end of the sale, it is advisable to release a report that details what actually happened, or didn’t happen as planned.

Ongoing Progress

Provide regular reports on progress with clear language, both from a technical and non-technical point of view.

Exchange Listing

This is a critical aspect where current practices are certain to crash the system. Tokens should not be listed before the start of the operations on the network, platform, or application. This is where many ICO’s seem to have lost their ways, and that’s risky.

In an ideal world, token issuers would not let their token trade prior to making the network operational. If the token is an App or Network or Protocol or Service Utility, why let it trade before your utility is operational? In the case of Ethereum, early crowdfund buyers held their tokens for a year before they could trade them. First, the Ethereum blockchain was turned ON, then the token became available in exchanges.

Yes, it is ok for speculation to occur, as it can help to fund the evolution of the project, but until the project is live, money raised should be the only economic incentive that is available to the team and to the market.

Part IV – Comprehensive List of Disclosures

There is a long list of required disclosures, and these help to elevate the confidence of the public and critics about the actual progress of the project and the credibility of the team behind it. The substance of the transparency reports is as important as the transparency itself.
If regulation were to be formalized around ICOs, I would suspect that a filing requirement would include several pieces of data from the following list:

List of disclosures: (Reference source: Token Filings)

    Pre-sale

  1. CEO Name, location and bio
  2. Crowdsale site
  3. Year Founded
  4. Founders country of residence
  5. Management and Advisors list
  6. Legal formation jurisdiction
  7. Token formation jurisdiction
  8. Number of employees
  9. Team’s list and bios
  10. Type of token being created
  11. Total token supply
  12. Token supply in circulation
  13. Future token monetary policy
  14. Exact token distribution allocation (pie chart)
  15. Locked-up periods per token ownerships
  16. Sale terms and conditions
  17. Clear communications re: pre-sale vs. crowdfund parts
  18. Type of token
  19. Type of raise: capped, uncapped, etc.
  20. Initial token price (in USD, as a reference point)
  21. Blockchain technology being used
  22. Audit report on smart contracts
  23. Names of service providers: ICO, PR, Legal
  24. Clear token functionality
  25. Statement of token governance
  26. Statement regarding exchanges

  27. Post-sale

  28. Number of participating addresses
  29. Participating countries
  30. Amount raised (in what currency)
  31. Plan for treasury (i.e. what will be sold into fiat vs. stored in crypto)
  32. Custody method for crypto and fiat currencies
  33. Audit report on funds receipt and distribution
  34. Regular transparency reports

Conclusion and Next Steps

When (not if) regulators start looking at ICO deals they might want to investigate, they will likely start with the ones that exhibit weaknesses. ICO projects that take seriously these best practices will be in better and safer positions than those who don’t.

It is not easy to prescribe generic advice for ICO projects, but the more we see good ICOs, the longer we can expect this to remain a healthy phenomenon, despite the fact that many ICOs are currently over-valued, over-funded or overly promoted.

I welcome feedback that leads to constructive iterations or enhancements on these thoughts.

ICOService: Contact Us

Free to contact us for any further information. We will be happy to consult you on our services, answer your questions, and help implement your business ideas.