Disclaimer

A recent ICO Quantstamp has started a marketing campaign titled “Proof of care” where their community can receive an allocation in their pre sale if they show some proof that they are interested in or care about the Quantstamp project. This can be in the following forms:

Reading the whitepaper, writing blog posts, telling people via telegram, suggesting partnerships, tweeting about our project, telling your friends, posting YouTube videos, posting in Facebook groups

In all honesty, at first sight this seemed like just an extremely well crafted marketing technique but I wanted to give the team the benefit of the doubt. So here, I will be doing a full review of the project without hyping the unrealistic or lying about the negative. In it's current form, I don't see very promising value out of this project. Therefore, the goal is to understand whether this is truly a proof of “care” program for the betterment of their project and the blockchain community or merely another hype machine as has been rampant in the crypto community. The reaction to this post from the Quantstamp team will determine the result.

Project

Background: It’s clear that a critical part of the blockchain infrastructure (for ethereum anyway) is the smart contracts. As smart contracts are written by humans, they are inherently exposed to error and security oversights. The DAO hack and the Parity Multi Sig Hack are great demonstrations of this problem.

The goal of the project is to provide a secure and scalable method for auditing of ethereum smart contracts to prevent this very issue. On initial thought this seems to be a very humanistic issue which could only be scaled by humans and the mastery of the tools and languages involved. So how could blockchain solve this issue? lets open up the white paper and find out.

After reading the abstract and overview section, it becomes clear that the purpose is not to actually automate the human security audits of smart contracts. There are 2 methods that are mentioned to solve these issues:

1. Automated and verified security checks

The platform will run automated security checks using various code analysis methods and achieve a concensus about the security of contracts on an independent network. This will allow end users of contracts or DAPPs to verify that something they are interacting with adheres to a certain level of security.

They intend to achieve this by implementing a “security library” which implements these security checks. This library then runs as part of the validator nodes and reaches a consensus on the network, identical to the way the state of a ethereum smart contract would be.

The benefit of this is that the end users are not at the mercy of the developers. Any client can verify to it’s own expectation of the security requirements before interacting with a smart contract.

The white paper briefly mentions that:

Quantstamp does not guarantee 100% that the source code is flawless

No automated tool for analysing code is always accurate in detecting or preventing vulnerabilities.
False positives are common.

When dealing with a decentralised model, if a given calculation is not truth (like math and cryptography is) then you are centralising the decision making of such calculations. i.e. the “security library” becomes the central point of authority. This could inhibit the creativity of smart contract authors and falsely mark a smart contract as insecure. There has not been enough detail dedicated to this problem in the white paper. The promises given have been to continually improve the security library although it becomes difficult to imagine how this would pan out given the immutability of data/code on chains.

2. Incentivising human auditors

There are mentions here and there about how nodes are able to independently do human verifications of the code and prove the code vulnerable.

In the process of an independent verification, human verifiers can use any means at their disposal to break the code, and if a smart contract is found to have major vulnerabilities, then the verifier is awarded the rolling bug bounty

While this sounds great, there is not nearly enough detail to explain this mechanism.

How do they envision hackers proving that a certain piece of code breaks without realising the intentions? Consider “It’s not a bug, it’s a feature”.
Could there be a staking mechanism involved where verifiers lose their bounty if an issue is found with the contract later?

Again this seems very indeterministic and feels like a centralised approach will be required with only the bounty payment being decentralised.

In summary: when considering what value this project will bring to the eco system, I will leave you with this question: What are examples of high profile smart contract exploitations that happened via known vulnerabilities that could have been detected via automation? Although undeniably the project can improve the baseline and long tail.

Token

The QSP token is used as reward for the verifier nodes. The QSP network seems to be it’s own blockchain implementation and therefore would not be able to use ETH for this purpose.

65% of the token supply is being issued which is appreciated. The hard cap for presale investors is 1/3 of the public token supply. There are many token sales recently that provide minuscule percentages of tokens for sale or assign a disproportionate amount to pre sale investors. The only issued identified is that they provide a 100% bonus to pre sale investors which is large but given their intent and requirements for an early strong following could be acceptable.

There is no detail about how/when QSP tokens will be transitioned to the QSP network.

Since this section is a bit light, lets try some of their medicine: audit their token smart contract (ironic lol)

I won’t go over the obvious - the standard practices are there and the code is in good condition overall.

The token allows a user to burn their own tokens and thereby decrease the total supply which is not conventional.
The token contract does a bad job at separation of concerns as it includes a disproportionate amount of logic related to the crowd sale. This is documented as needing to associate a number of tokens to the crowdsale at a later time. This could have been implemented as the crowdsale holding a balance of the tokens which would be transferred to it at a later time by the supply owner.

Team

Good array of people with relevant experience. Advisors are notable including Evan Cheng that advised Chainlink. I won’t comment on individual contributions as it’s very difficult to objectively assess with the exception of the person/agency responsible for the website. A wordpress site for a one page layout and design which is reminiscent of “web 2.0”. It’s lacking professionalism for a project that is intending to raise this much.

That concludes my take on this ICO