Lessons from an ICO

Despite the fact that they’ve been around in one form or another since 2014, ICOs are still the new kids on the block. As the new kids there is still a lot of uncertainty about what, exactly, an ICO is. Is an ICO a security? Is it a utility? Is it both? Neither? Because of this uncertainty we’re all still figuring out the safest and most secure way to run an ICO. In 2018 we are starting to see regulations come down from the SEC and because of that crossing t’s and dotting i’s has never been more important.

With SEC intervention in the ICO market practically guaranteed to increase throughout 2018 (I mean the SEC went and built a fake ICO to warn investors) it’s more important than ever to go into the process of hosting your private and public sales with a trusted partner who has gone through the process before and has the battle scars to prove it.

At Tanooki Labs, while we’ve been working on our own projects leveraging the advantages of the Ethereum blockchain, we’ve also been helping some of our clients in preparing and running their own ICOs. One of our last projects was a two month blitz to create the infrastructure necessary to support a $19M public sale with complete SEC-compliance. Needless to say we learned a lot. So we thought it would be helpful to the community to break it down into notes for PMs, Devs and CTO/Business Owners and let those who lived the ICO give their tips. First up, advice from our lead developer on the project, Ryan Boland.

For this project we leveraged ICOBox for its book building capabilities and Cynopsis for automating the KYC (Know Your Customer), AML (Anti-Money Laundering) and checks against other blacklists. We also utilized InvestReady to ensure that people in the US purchasing large amounts of tokens were accredited investors.

Know your customer (alternatively know your client or ‘KYC’) is the process of a business identifying and verifying the identity of its clients. The term is also used to refer to the bank and anti-money laundering regulations which governs these activities. (Wikipedia)

So, what did we learn?

Some general thoughts:

  • Developers should coordinate early with the final product owners to determine the precise legal requirements and what information needs to be collected. Remember that the guidelines are there, but it’s up to the product owner to define exactly what they’d like to implement since they’re still guidelines and not requirements.

  • Start development as far ahead of the ICO as possible (a minimum of 3 months is a good target). You want to test the application extensively prior to going live.

  • Off the shelf solutions like ICOBox can be a good starting point. But they will need to be set up, customized, and monitored by experienced developers. There’s no truly out of the box system that’s ready for prime time.

  • Don’t forget to start partnership conversations with partners like Cynopsisearly as well. Contract negotiations can drag on, and last minute integrations can impact security and performance!

Security and Stability

  • Your ICO will be a popular targets for hackers. A relatively large amount of time should be budgeted for security, even outside of the 3 months listed above. In addition independent penetration tests and security audits should be a requirement, not an option.

  • If you expect to generate a lot of excitement around your ICO, application performance will also be important. The application should ideally be hosted on a scalable infrastructure (such as Heroku).

Overall, running an ICO isn’t terribly complicated from a development standpoint. The applications are not extremely complicated, but the security, performance, and third party integrations can make things take longer than originally expected. As usual, always budget extra time!

Thanks to Eric Skiff and Travis Pew.