Audit Report
NExTLabs Smart Contract Audit

# 1. Introduction
iosiro was commissioned by NExTLabs to conduct an audit on their token smart contracts. The audit was performed between 26 October 2018 and 29 October 2018.

This report is organized into the following sections.

* **[Section 2 - Executive Summary:](#section-2)** A high-level description of the findings of the audit.
* **[Section 3 - Audit Details:](#section-3)** A description of the scope and methodology of the audit.
* **[Section 4 - Design Specification:](#section-4)** An outline of the intended functionality of the smart contracts.
* **[Section 5 - Detailed Findings:](#section-5)**  Detailed descriptions of the findings of the audit.

The information in this report should be used to understand the risk exposure of the smart contracts, and as a guide to improve the security posture of the smart contracts by remediating the issues that were identified. The results of this audit are only a reflection of the source code reviewed at the time of the audit and of the source code that was determined to be in-scope.

<a name="section-2"></a>
# 2. Executive Summary

This report presents the findings of an audit performed by iosiro on the NExTCoin token, as well as a generic token smart contract template used to implement 13 additional tokens. The purpose of the audit was to achieve the following.

* Ensure that the smart contracts functioned as intended.  
* Identify potential security flaws.

Due to the unregulated nature and ease of transfer of cryptocurrencies, operations that store or interact with these assets are considered very high risk with regards to cyber attacks. As such, the highest level of security should be observed when interacting with these assets. This requires a forward-thinking approach, which takes into account the new and experimental nature of blockchain technologies. There are a number of techniques that can help to achieve this, some of which are described below.

* Security should be integrated into the development lifecycle.
* Defensive programming should be employed to account for unforeseen circumstances.
* Current best practices should be followed wherever possible.  

At the conclusion of the audit, two low risk issues were open, as well as informational findings and design recommendations. The low risk issues resulted in the generic token contract including code that was unusable and potentially prohibiting the token from working with third party contracts due to using 0 decimal places. The informational findings included minor deviations from best practice and suggestions that may improve the functionality of the code.

Despite the findings, the code was of a relatively high standard. This was evident in the use of modularized code, as well as making use of commonly used libraries where reasonable.

The risk posed by the smart contracts can be further mitigated by using the following controls prior to releasing the contracts to a production environment.

* Use a public bug bounty program to identify security vulnerabilities.
* Perform additional audits using different teams.
* Extending the test suite coverage.

<a name="section-3"></a>
# 3. Audit Details
## 3.1 Scope
The source code considered in-scope for the assessment is described below. Code from any other files are considered to be out-of-scope.
### 3.1.1 NExTCoin (NTX) Smart Contract
<!-- **Project Name:** NExTCoin <br/> -->
**Link:** [0xae785cbf3c9670c3e5a5dd0053dec05a4aada688](https://etherscan.io/address/0xae785cbf3c9670c3e5a5dd0053dec05a4aada688#code)<br/>
<!-- **Files:**  -->

### 3.1.2 Generic Token Smart Contract
A generic token smart contract was used to implement 13 different tokens. The only variable features between the different versions were the contract name, token symbol, token name, and token total supply. The source code for each of the tokens can be found below.

|Token Name       | Contract Address Link
|:------------ |:-------------
|RESERVE Coin       | [0x5dab189977f37a58d9f52f3473f49bf5506a9517](https://etherscan.io/address/0x5dab189977f37a58d9f52f3473f49bf5506a9517#code)|
|SUPRA Coin         | [0xcdf77671cda83585ef64a67f3266bb51862c8cf3](https://etherscan.io/address/0xcdf77671cda83585ef64a67f3266bb51862c8cf3#code)|
|AMBASSADOR Coin     | [0x96dc85fc195b7bb3eaeb2181e7e710e2918ab98d](https://etherscan.io/address/0x96dc85fc195b7bb3eaeb2181e7e710e2918ab98d#code)|
|UNIVERSAL Coin | [0xa15880c218d8f533f2825cdcee59e11fac942120](https://etherscan.io/address/0xa15880c218d8f533f2825cdcee59e11fac942120#code)|
|ONE Coin | [0x09e3f27d540edbcd9a6b3e75dcae501ecaed510b](https://etherscan.io/address/0x09e3f27d540edbcd9a6b3e75dcae501ecaed510b#code)|
LEGACY Coin | [0x9b66270a18f696711a56cec0cdd1f7801433536f](https://etherscan.io/address/0x9b66270a18f696711a56cec0cdd1f7801433536f#code)|
|PREMIERE Coin | [0xaa19a4bdb4aa3f77b025afd78c1cc6d1851222db](https://etherscan.io/address/0xaa19a4bdb4aa3f77b025afd78c1cc6d1851222db#code)|
|FREEDOM Coin | [0x4f780f0693a5dec6bb4481dae7061004d3a0ae28](https://etherscan.io/address/0x4f780f0693a5dec6bb4481dae7061004d3a0ae28#code)|
|PEACE Coin | [0x0ae1c8251ca78508f0c7458bd4067d4423bd1e0a](https://etherscan.io/address/0x0ae1c8251ca78508f0c7458bd4067d4423bd1e0a#code)|
|ICOSA AQUA Coin | [0x8ed5004542f7b98a3c08e1f3471586ca66a082aa](https://etherscan.io/address/0x8ed5004542f7b98a3c08e1f3471586ca66a082aa#code)|
|FIRSTWORLD Coin | [0x7bf89e99da54db3f9b4090ad483fe992b5152303](https://etherscan.io/address/0x7bf89e99da54db3f9b4090ad483fe992b5152303#code)|
|MNEMONIC Coin | [0xd94f31ea5883199522f045866aa0340bfae4881e](https://etherscan.io/address/0xd94f31ea5883199522f045866aa0340bfae4881e#code)|
|PRIMEBANK Coin | [0x6a41250a0f864cb9f53d043cb961091514a7b06b](https://etherscan.io/address/0x6a41250a0f864cb9f53d043cb961091514a7b06b#code)|

## 3.2  Methodology

A variety of techniques were used to perform the audit, these are outlined below.

### 3.2.1 Dynamic Analysis

The contracts were compiled, deployed, and tested using both Truffle tests and manually on a local test network. No test suite was included in the supplied project code.

### 3.2.2 Automated Analysis

Tools were used to automatically detect the presence of potential vulnerabilities, such as reentrancy, timestamp dependency bugs, transaction-ordering dependency bugs, and so on. Static analysis was conducted using Mythril and Oyente. Additional tools, such as the Remix IDE, compilation output and linters were used to identify potential security flaws.

### 3.2.3 Code Review
Source code was manually reviewed to identify potential security flaws. This type of analysis is useful for detecting business logic flaws and edge-cases that may not be detected through dynamic or static analysis.

## 3.3  Risk Ratings

Each Issue identified during the audit is assigned a risk rating. The rating is dependent on the criteria outlined below..

* **High Risk** - The issue could result in a loss of funds for the contract owner or users.
* **Medium Risk** - The issue results in the code specification operating incorrectly.
* **Low Risk** - A best practice or design issue that could affect the security standard of the contract.
* **Informational** - The issue addresses a lapse in best practice or a suboptimal design pattern that has a minimal risk of affecting the security of the contract.
* **Closed** - The issue was identified during the audit and has since been addressed to a satisfactory level to remove the risk that it posed.

<a name="section-4"></a>
# 4. Design Specification
The following section outlines the intended functionality of the smart contracts.

## 4.1 NExTCoin (NTX) Token
The NExTCoin (NTX) token is described below.

#### ERC-20 Token

The token should implement the ERC-20 standard.

|Field        | Value
|:------------|:-------------
|Symbol       | NTX
|Name         | NExTCoin
|Decimals     | 0
|Total Supply | 105,000,000,000 (NTX)

## 4.2 Generic token smart contracts
The generic token is described below.

#### ERC-20 Token

The token should implement the ERC-20 standard.

|Field        | Value|
|:------------|:-------------|
|Symbol       | `SYMBOL`|
|Name         | `NAME`|
|Decimals     | 0|
|Supply Cap   | Set during initialisation|

#### Pausable

It should be possible for the contract owner to halt the transfer of tokens by pausing the token contract.

#### Burnable

It should be possible for tokens to be removed from the total supply by using the built-in token burn functionality.

#### Mintable

It should be possible for the contract owner to mint tokens until the supply cap is reached.

<a name="section-5"></a>
# 5. Detailed Findings
The following section includes in depth descriptions of the findings of the audit.

## 5.1 High Risk

No high risk issues were present at the conclusion of the audit.

## 5.2 Medium Risk

No medium risk issues were present at the conclusion of the audit.

## 5.3 Low Risk

### 5.3.1 Extended Token Functionality Not Implemented

*Generic Token Template Contract: Line 410*

#### Description

The audit revealed that parts of the generic token codebase were not available to users, despite being implemented in code.  This was due to the fact that some mixins (`BurnableToken`, `MintableToken`, and `PausableToken`) were not inherited by the token contract itself despite being compiled in the contract code. This resulted in the functionality available in these mixins not being callable. It was found that only the `StandardToken` mixin was inherited. As tokens could be manually burned through sending tokens to `0x0` and tokens were only minted upon initialization of the contract, the main concern would be that the pausable functionality was not implemented.

#### Remedial Action

It is recommended that line 410 of the generic token smart contract template be altered so as to include the functionality required. For example, changing line 410 to:

`contract PRIMEBANKCoin is PausableToken, MintableToken, BurnableToken {`

### 5.3.2 Token Uses No Decimal Places

*Generic Token Template Contract: Line 414*

#### Description
It was identified during the audit that the generic token implementation used 0 decimal places. This could cause problems when interacting with other smart contracts, as tokens with 0 decimals can cause rounding errors. For example, many exchanges charge a small fee based on the tokens exchanged. As such, using no decimals will either make it impossible to list the token on these exchanges or it will result in having expensive fees compared to other tokens.

#### Remedial Action

It is recommended that decimal places are used for the token contracts. This can be done by setting the `decimals` variable to the required number of decimals. A commonly used value for ERC-20 tokens is 18 decimals.  

## 5.4 Informational

### 5.4.1 Design Comments

Actions to improve the functionality and readability of the codebase are outlined below.

#### `decreaseApproval(...)` function consumes unnecessary gas

*Generic Token Template Contract: Line 232 and NExT.sol: Line 240*

It was found that the `decreaseApproval(...)` function used gas unnecessarily by using a greater-than operator in the conditional check, instead of a greater-than-or-equal-to operator. Although not strictly a security or functional issue, it is recommended that line 240 be changed to:

`if (_subtractedValue >= oldValue) {`

#### Defining constructors as functions with the same name as the contract

In several cases it was found that contract constructors used the deprecated convention of being declared as functions with the same name as the contract. Although, there were no cases where this would contribute to a security or functional issue. It is recommended that the `constructor(..)` format is used in place of the deprecated format.

#### No `require` validation failure messages provided

It was found that no `require` validation calls made use of the optional error message parameter. Although strictly not a security or functional issue, it should be resolved to provide better feedback in cases where validation fails.

#### Use of implicit integer sizes in contract implementations

It was found that several properties and functions contained implicit `uint` type declarations. It is suggested that these `uint` type declarations be replaced by the `uint256` type declaration instead in order to adhere to best practice.

#### No emit keyword

The emit keyword was found to be missing before events. This style has been deprecated, so it is recommended that the `emit` keyword is added before each event, e.g. `emit Transfer(...)`.

#### Inexact solidity compiler version used

The pragma version was not fixed to a specific version, as it specified `^0.4.21` for NExT token and `^0.4.18` for the generic token contracts, which would result in using the highest non-breaking version (highest version below `0.5.0`). According to best practice, where possible, all contracts should use the same compiler version, which should be fixed to a specific version. This helps to ensure that contracts do not accidentally get deployed using an alternative compiler, which may pose the risk of unidentified bugs. An explicit version also helps with code reuse, as users would be able to see the author's intended compiler version. It is recommended that the pragma version is changed to a fixed value, for example `0.4.21`.

## 5.5 Closed

No issues were closed at the conclusion of the audit.

Secure your system.
Request a service
Start Now