Alright, so I’m not going to waste a lot of time, because I just want to get right to it.
For anyone that has a pulse, you’ll remember that $BNT had their platform “audited” by Quantstamp about a month or so ago.
In that audit, several flaws within Bancor’s Protocol were discovered.
A week or two later, the entire report was retracted spontaneously via a message on Reddit.
This felt peculiar to me given the fact that there was no greater information on why the audit rendered ‘false positives’.
Does this mean that $QSP simply does not work? Or was this something a bit deeper?
This article will be targeted at getting to the core of these issues.
The reason why I’m interested is because this could be a major issue if it does exists and no matter what the outcome of this situation is, there are implications that must be considered.
I’ll discuss those in greater depth within this article and demand the answers that should have been given voluntarily by both teams weeks ago.
Description of the Problem
So, let’s start with Bancor Network.
It’s an ERC20 token and to summarize its purpose as briefly as possible, its designed to provide liquidity for other ERC20 tokens. I’m not going to dive any deeper than that, because this isn’t a Bancor Network coin review.
Here’s a link to the whitepaper for Bancor Network:
It’s worth noting that this whitepaper can not be found on the Bancor website for some reason.
Go ahead and Google: “Bancor Whitepaper”
While commenting on Bancor, one of the things that I mentioned prior is how a user (no one knows who) used the protocol to perform an audit.
What is Quantstamp?
Quantstamp ($QSP) is a smart contract auditing platform. So, they review/audit smart contracts to see if there are any flaws/vulnerabilities/potential exploits in the code that they run on.
For those that don’t know:
ERC20 token = smart contract.
ERC20 tokens are launched on Ethereum’s blockchain. I’m summarizing here for the sake of getting to the point. There is a LOT more about ERC20 tokens and smart contracts that is not covered in here, but this knowledge is sufficient for the purposes of understanding the issue at hand in this article.
So, you can see how Quantstamp’s platform would be of useful in the world of crypto.
Their smart contract auditing services can be purchased by anyone and applied to any code. The audit is automated (there’s not a human being performing it), and it uses Oyente (which, if this is the case, what is the purpose of Quantstamp? But moving on)
Results of the Audit
So, as stated earlier in the article, someone else commissioned the audit of Bancor’s code.
If you attempt to retrieve the report at this moment in time, you’ll get this message:
What’s interesting, is out of the 464 audits that it has reportedly completed, this is the only audit that rendered a “false positive”.
Crazy odds, right?
To be clear, this is the definition of a “false positive”, in a computer sense.
There are Two Types of False Positives:
The reason why I wrote this article, is because it’s difficult, if not impossible to find out what the “false positives” were AND (keyword and), WHY (keyword why) these findings were determined to be false positives.
The most that I’ve been able to find from Quantstamp themselves is this Reddit thread:
In the thread, several links are posted:
The link in the picture above takes us right back to that same page that I displayed above. I’ll post it here again for prosperity though:
Even the FinanceMagnates article fails to specify what exactly was contained within the $QSP audit.
However, I’m a crafty and resourceful individual. So, you know I doggedly searched until I found the original iteration of the report.
This is an archived copy of an article about the report, which was originally published by The Merkle.
Here’s a great excerpt from the article that really summarizes the meat and bones of the audit itself:
I’d like to bring your attention to the following statements:
“The first flaw occurs when BancorConverter contract executes the state of another contract. According to Quantstamp, this can create a problem, as it takes ‘little skill to exploit’ the reentrancy flaw. The company even highlighted the line of code which is at risk, and it will be interesting see whether or not Bancor addresses this problem soon.”
Wait, Did They Just Say Reentrancy?
Yes, they did.
This is the same error that has been isolated in Bancor’s code time and time again by various different and unrelated entities over the course of the last year.
So, let’s do this issue justice and cover each time that this issue was mentioned as a pressing concern on the Bancor protocol. Don’t worry, when I won’t skip over any of the Bancor responses.
We’re going to hash this issue (haha, get it?) out once and for all (serious now).
However, before we do, let’s explore what the hell this “reentrancy” problem is, shall we?
Check out this article. It covers the reentrancy issue, but not in the context of Bancor. It just looks at the problem in a vacuum through a hypothetical lens.
Fortunately, Medium has allowed me to embed the pdf.
Here are the relevant pieces that you need to view though:
Oyente is important to pay attention to because Oyente is intertwined with $QSP.
I posted a picture explaining what Oyente was a bit earlier, but I’ll repost it here again for posterity purposes:
So, it’s a “…analysis tool designed to check for flaws in executable distributed code contracts (EDCCs).”
This is the tool that $QSP uses to perform the smart contract audits.
Do your homework on Lee Azzarello and the information will check out.
I even have a guideline for how you should direct your research if you’re curious as well:
- Google Lee Azzarello. Gather information.
- Google “Lee Azzarello Quantstamp”. Verify that relationship.
- Google “Lee Azzarello Oyente”. Verify that relationship.
Sift through the links. Validate the source. Verify the information. Don’t read into anything that’s not there.
This isn’t a controversial relationship at all, so it won’t be hidden or obfuscated. I just wanted to post this up here to help others with their researching skills and get a feel for how I like to operate.
Back to the issue at hand — reentrancy problems.
Remember, the pdf stated, “Loi et al.  propose a symbolic execution tool called OYENTE to find 4 kins of potential security bugs. They discover that 8,833 out of 19,366 Ethereum smart contracts are vulnerable.”
So, one of the core purposes of this smart contract audit is to find four different issues in a given smart contract, which are:
Everything isolated above is important because it sets the stage for the information that’ s going to follow in this article and definitively show what Bancor and Quantstamp are engaged in some seriously dishonesty.
Let’s pay close attention to the definition of Reentrancy vulnerability.
What’s written is, “During the invocation of the smart contract, the actual state of the contract account is changed after the call is completed. An attacker can use the intermediate state to conduct repeated calls to the smart contract. If the invoked contract involves Ether transaction, it may result in illegal Ether stealing.”
Wait, did that just say, “…may result in illegal Ether stealing” ?
That’s a huge deal. So, even if there’s a minute, teeny tiny potential for such an exploit, that’s something that should be handled, right? Right.
The rest of this paper will be dedicated to covering all of the different instances where this problem was covered in full by different entities within the community.
Bancor’s response will be covered as well. Also, I have reached out to multiple different involved parties in order to get a better idea of what’s going on as well.
#1 — Let’s Go Over the Review From the Cornell Researchers
Here’s the article: http://hackingdistributed.com/2017/06/19/bancor-is-flawed/
This came out in June of 2017 after the Bancor ICO.
There were a number of issues that they raised about Bancor, but I’m focused on the reentrancy problem, in specific, as I’m sure you’ve figured out by now.
Here’s What the Cornell Researchers Said About the Reentrancy Issue on Medium:
Sure, the criticisms in the excerpts above are scathing, but let’s commit to extracting the most pertinent pieces.
The parts that are most relevant are “Bancor has a reentrancy problem in the sell () function”
“Bancor code has a different reentrancy problem in the change () function”
Whether it is/was exploitable or not, remains to be seen. What is notable though is that the existence of the ability to commit a state change within the token promulgates the potential of an attack vector for no apparently good reason.
In plain English, there’s no reason for this code to exist in the smart contract. At all. And it should have/been/be removed.
Let’s look at Bancor’s response to this.
Bancor’s Response to the Cornell Researchers:
To Bancor’s credit, they did post a response to the Cornell researchers. In the same way that I refrained from going over all of the nitty gritty details outside of the reentrancy problem in the Cornell research, I’m going to do the same here for the response and just focus on their rebuttal to that sole issue.
Here is the link to their response (from their platform on Medium):
I Have Posted Their Response to the Reentrancy Issues Raised in the “Hacking, Distributed” Magazine in Full Below:
(The first few posts are unnecessary, but the last ones do get to the heart of this issue)
Finally, here’s the steak and eggs. Let’s dissect, shall we?
This part of their response is dedicated to addressing the issues that were brought up re: reentrancy problem in the sell() function.
In the response, Bancor lists all of the external calls in their code.
Let’s break down this feature in a little more depth, to make this more palatable to the average reader that’s not familiar with Bancor’s system of providing liquidity.
From another post of theirs:
“Secondly, anyone can purchase a smart token with its reserve token(s), simply by transferring the reserve token to the smart token’s contract, which in return issues the buyer new units of the smart token. This is similar to the way tokens are issued by ICO smart contracts in exchange for other tokens (such as Ether). However, with smart tokens, the reverse operation is also possible, meaning that any smart token holder can choose to liquidate units and receive a reserve token in return, effectively removing these smart token units from circulation, and all this is done directly through the smart token’s contract. The supply of a smart token increases and shrinks with demand for it.”
So, suppose you created $OMG and you’re using Bancor for liquidity. You could have those $OMG tokens swapped for “reserve tokens” from Bancor. That’s where the external call stems from.
The purpose, of course, would be to remove tokens from circulation in an escrow-like reserve holding. Of course, as the price moves up or down, there’s an automated calculation within the Bancor protocol which is supposed to adjust the price in order to ensure that the reserve is never entirely depleted.
Given this information, it strikes me as extremely odd that $QSP would retract the audit without providing any reliable information as to why the audit was retracted.
While I hate to publish such an article on $QSP, I feel as though it is one that MUST be posted in lieu of all of the information that I discovered on this issue.
I pushed the $QSP team for a response on their behaviors and they refused to give me one. So, I am forced to publish this article in hopes that it will prompt a greater response from the team to provide much needed transparency in the space.