Smart Contract — Security Audit

With our Token Generation Event fast approaching, we have been hard at work finalising our smart contracts, which will be used to facilitate the event. To ensure these contracts are both secure and high quality, we utilised best-in-class software development and engineering practices. We decided to take a Test Driven Development (TDD) approach from the beginning and we’ve managed to include test coverage for over 99% of lines and statements, 88% of branches and 100% of functions.

We took great care to make sure the code is well documented, every line was peer reviewed before ending up in the master branch and we kept a clean commit history (go rebase!), all to make our contracts more robust and easy to maintain.

Smart contract code coverage report — you can run the coverage tool by executing npm run coverage.

But of course we didn’t want to stop there. Our plan for further testing and tightening the code base consisted of three actions:

  1. Getting the code reviewed by an external, reputable auditor
  2. An end to end deployment and test-run on the Ropsten network
  3. A public Bug Bounty Program, asking the community for their valuable input

Details about our Ropsten testing event and our Bug Bounty Program will be announced in the coming days. This post, however, aims to focus on the security audit we conducted.


Token Sale Code Review

Adrià, of Codecontext, has over 18 years of experience in security, cryptography and digital identity software development. He has previous worked with projects such as Stox and SkinCoin, carrying out code reviews and security audits.

We asked Adrià to review our Token Sale repository which includes smart contracts for SHP and our upcoming crowd-sale, and were very pleased to receive his conclusion on our work.

“The reviewed smart contracts are well crafted, following the expected common security practices. They contain non-trivial logic but a full set of tests are provided to enforce their correctness. No critical problems have been found, and potential problems can be avoided with a careful (as expected) operation by my Sharpe Capital team. We recommend proceeding to a public bug bounty program, as usual in public token offerings.” — CodeContext.io

The full report can be dowloaded here, which was based on the following commit.

We’re very happy to see there weren’t any critical issues with the code. The report points out a few potential problems (section 3.3) and some minor issues (section 3.4), which we’ve taken the time to address. The resolved issue are discussed in the rest of this blog post.


Problem: The use of privileged (onlyOwner) functions to construct and modify parameters, some of which could be changed during the sale.

Solution: We had used privileged functions to set parameters such as contribution rages and caps inPreSale.Sol. By removing these functions and setting the parameters in the contract’s constructor instead, we can ensure that these values cannot be modified during the sale (change commit). We also made additional checks to ensure onwership of the TokenController cannot be passed onto a zero address (change commit).

In addition to this, we will be using a script to deploy and initialise all smart contracts, in a similar fashion as our end to end test to ensure no errors are made.


Problem: Presale.addToWhitelist() will not consistently update whitelistedPlannedContribution if called twice with the same address.

Solution: With this change, we add a check to ensure each address is only whitelisted once.


Problem: If in PreSale.processPreSale()the amount reaches the cap without any refund, then closePreSale() is not called automatically.

Solution: This commit address this issue by making sure reaching the cap closes the sale when the last cobtribution equals the remining cap. Additional test cases have also been added to cover this edge case.


We also addressed some the minor comments by:

  • Making some functions constant (commit)
  • Making SHPController conform to TokenController interface (commit)
  • Added licence notes to all contracts and attributed credit for our use of DynamicCeiling.Sol (commit)

Prior to the review, we also discovered a potential issue with the use of msg.data from our Affiliate Scheme. This issue, and its resolution, is discussed in this blog post.

Get In Touch

If you’re interested in our pre-sale, or simply want to learn more about our project, feel free to get in touch at hello@sharpe.capital.

Twitter: https://twitter.com/sharpecapital

Telegram: https://t.me/sharpecapital