Request Network Token Sale Smart Contract Security Audit Summary

Recently, we at Quantstamp audited Request.Network’s token sale smart contract to help them guarantee a safe and secure token sale.

The audited contract is available here:

In summary, the Request Network token sale smart contract overwhelmingly passed our security audit. General observations include:

  • significant use of widely-tested open source code;
  • strong adherence to best-practices;
  • a choice of simplicity over complexity;
  • comprehensive code coverage with unit tests; and
  • a cautious use of guards/modifiers to eliminate large swarms of vulnerabilities.

In security, we must expect the unexpected and the Request.Network smart contract takes this mantra to heart. The ample use of the onlyOwner guard ensures that access to certain functions during the crowdsale is constrained to a trusted Ethereum account. They have carefully guarded against reentrancy exploits, like the kind that plagued the DAO last year, and the use of a safe library for mathematical operations avoids problems with integer overflow. We also consider it very sensible to have a drain function that allows the Request Network team to extract tokens sent by mistake to the contract.

Request.Network thoroughly impressed us by the amount of care and attention to detail they’ve put into their code. We only observed some very minor issues. They immediately addressed our nitpicks and have made an already fantastic token sale smart contract even better.

We did notice one thing about Request.Network’s automated test suite — it didn’t work right away. It’s important to ensure that test files are executed in a deterministic manner, but the state of the blockchain time data did not appear to update properly in between test files. This would cause the creation of the RequestTokenSale contract to fail due to the startTime parameter not being greater than now. In order for all tests to function properly, the addsDayOnEVM() function was called appropriately before each creation of a RequestTokenSale.

We identified one faulty test case due to a hard-coded date value. This test ensures that RequestTokenSale cannot be instantiated with an end-date before the start-date. The hard-coded date caused unforeseen interaction with the actual current date, which presumably did not occur when the test was originally written. After updating the constant to an appropriate value, the test passed as expected.

Presently, we perform a mix of human and automated checks. As our project matures, we’ll be automating more of our auditing process. We aggressively test for certain vulnerabilities using static analysis and reachability procedures. Meanwhile, our Senior Software Engineer, Ed is developing a powerful fuzzer for automatic test-case generation. At this time, the fuzzer requires Ed’s expertise to make tweaks from project to project, and he’s working towards generalizing it for wider use.

One challenge of programming in Solidity is that what you think is happening might not actually be the case (aka “semantic gaps”). At each step of the way, our engineers take the mindset of “the attacker”. We question every design decision, every line of code, and envision that millions of dollars are at stake. We trace through scenario after scenario, and map each back to the EVM execution model.

One of the most important things we do as a team is endlessly ask one another, “What if?” What excites us about this approach is how new ideas for automation emerge that will strengthen our security library. That’s what happens when you put a bunch of white-hat hackers in a room together. Eventually, our scalable, decentralized model will put tens of thousands of white-hat hackers with advanced automated reasoning tools in a room together asking “What if?” and testing those scenarios in a consensus based environment

We’re thrilled to have formed a partnership with Request.Network. Not only are we excited about their project, Etienne (CTO) and Vincent (lead developer) are great blockchain visionaries who share our belief in the future of the blockchain to improve people’s lives.

About Request Network

Request is a decentralized network that allows anyone to initiate a payment (a Request Invoice) for which the recipient can pay in a secure way. All of the information is stored in a decentralized authentic ledger. This results in cheaper, easier, and more secure payments, and it allows for a wide range of automation possibilities. Request integrates a general ledger (in the accounting sense of the term), designed to support 100% of global transactions, regardless of currency, legislation or language. Request can be seen as a layer on top of Ethereum, which allows requests for payments that satisfy a legal framework. Please see the Request Network whitepaper for more.

About Quantstamp

The Quantstamp protocol solves the smart contract security problem by creating a scalable and cost-effective system to audit all smart contracts on the Ethereum network. Over time, we anticipate every Ethereum smart contract to use the Quantstamp protocol to perform a security audit.l. The protocol consists of two parts: 1.) An automated and upgradeable software verification system that checks Solidity programs. The conflict-driven distributed SAT solver requires a large amount of computing power, but will be able to catch increasingly sophisticated attacks over time. And 2.) An automated bounty payout system that rewards human participants for finding errors in smart contracts. The purpose of this system is to bridge the gap while moving toward the goal of full automation. Check out our website to learn more.