Originally published on medium.

ICOs are a hot topic nowadays. Many of the recent write-ups discuss the valuation aspect of token crowdsales. In this post I will take a different angle and explore the code quality of smart contracts used in ICOs.

There are many tools and practices used to ensure decent software quality. Among others: unit-tests, code reviews, continuous integration, static code analysis, code coverage, mutation testing, formal verification, and following security standards like OWASP or PCI DSS. The more critical the software, the more thorough the quality assurance usually is. For closed-source software, one has to rely on industry practices and professionalism of the companies and individuals. For open-source software different rules apply: it’s easy to assess the quality of publicly shared code.

The ecosystem for developing smart contracts has evolved greatly over time. It’s easy now to do the basics: write unit-tests (in Solidity, Python, JavaScript) and even measure the code coverage. Along with bug bounties and 3rd party audits, there should be little doubt about the quality of smart contracts, right? Let’s see how it looks like in practice for some of the recent ICOs.

Project overview

BAT

BAT contracts have been audited and many errors have been fixed before the ICO. Sadly, we have no unit tests nor usage of any templates, just pure code.

Score: 0

Bancor

The Bancor Protocol contracts are a different beast. Despite using truffle framework and tests, there exist many deficiencies in the test coverage. Especially, the self-implemented math functions (exp, log) are insufficiently tested (see points 20–22). Plus points go for usage of jupyter notebooks for proving formulas and algorithms. Sadly, due to missing CI, some errors in the notebooks are left unnoticed (like undefined testCornercase2).

Score: 1.5 (low test coverage, jupyter notebooks)

Storj

Storj contracts use python integration tests and the OpenZeppelin contract templates. Plus for a nice readme with instructions for compiling and testing the contracts.

Score: 3 (tests, template usage, readme)

Aragon

Aragon contracts use both OpenZeppelin and MiniMeToken as templates. Along with CI we also have a quite active project with many pull requests and code-reviews, which are rather expected in an open-source project, but not really that visible in the other contract repositories.

Score: 4 (tests, template usage, CI, code reviews)

Status.im

Status contracts, besides being based on MiniMeToken, introduce an interesting novelty: continuous integration, including a build with test execution orchestrated by truffle framework along with execution details and migration tests. On top of that we get public audit results. Great transparency.

Score: 5 (tests, template usage, CI, detailed test results, audit results)

Summary

A quick glimpse into the source code reveals how serious founders approach product development and ICOs. There are already very good examples of ICO contracts to learn from. As the ecosystem continuously evolves, here some projects and initiatives to follow (and contribute to):

Final words

What happens if the founders are in for quick ICO money, deploy sloppy code or are unlucky to hit an yet unknown error? In the worst case your funds will be locked forever, like the $250,000 lost in smart contracts till date. If you have basic coding skills, you are privileged and can review the contract’s source code, or even try it out on the Ethereum testnet. For all others, the usual advice applies: don’t invest money you cannot lose.

So, coming back to the original question: would you trust your money to a smart contract?