CurrentCoin Token Smart Contract Audit
# 1. Introduction
iosiro was commissioned by [CurrentCoin](https://www.currentcoin.io/) to conduct a smart contract audit on their CurrentCoin ERC-20 token. The audit was performed on 18 September 2020.
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 better understand the risk exposure of the smart contracts, and as a guide to improving the security posture of the smart contracts by remediating issues 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.
The purpose of this audit was to achieve the following:
* Identify potential security flaws.
* Ensure that the smart contracts adhered to the ERC-20 standard.
Assessing the off-chain functionality associated with the contracts, for example, backend web application code, was out of scope of this audit.
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. Strategies that should be used to encourage secure code development include:
* Security should be integrated into the development lifecycle and the level of perceived security should not be limited to a single code audit.
* Defensive programming should be employed to account for unforeseen circumstances.
* Current best practices should be followed where possible.
<a name="section-2"></a>
# 2. Executive Summary
This report presents the findings of an audit performed by iosiro on the CurrentCoin ERC-20 token.
#### Audit Findings
iosiro noted two informational issues related to the versions of Solidity and OpenZeppelin contracts used, and made two additional design comments about code clarity and concision. The CurrentCoin implementation was compliant with the ERC-20 standard and introduced little extra functionality, but used old names for some common functions which are not part of the standard.
#### User Concerns
Users of CurrentCoin should note that the token has a fixed supply of 100 billion. The owner of the contract can pause and unpause transactions at will, and while the contract is paused, one or more administrators appointed by the contract owner will still be able to transfer tokens as normal. Additionally, users should be aware that CurrentCoin implements `increaseApproval(...)` and `decreaseApproval(...)` functions rather than the newer `increaseAllowance(...)` and `decreaseAllowance(...)` functions. These functions have almost identical behavior, except that the approval functions can be called with zero addresses, and the `decreaseApproval(...)` function will accept an amount greater than the current allowance, whereas `decreaseAllowance(...)` will revert.
#### Recommendations
At a high level, the security posture of CurrentCoin could be further strengthened by:
* Remediating the issues identified in this report and performing a review to ensure that the issues were correctly addressed.
* Performing additional audits at regular intervals, as security best practices, tools, and knowledge change over time. Additional audits over the course of the project's lifespan ensure the longevity of the codebase.
* Creating a bug bounty program to encourage the responsible disclosure of security vulnerabilities in the system.
<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 all other files is considered to be out-of-scope. Out-of-scope code that interacts with in-scope code is assumed to function as intended and introduce no functional or security vulnerabilities for the purposes of this audit.
### 3.1.1 Smart Contracts
* **Project Name:** CurrentCoin
* **Address:** [0x347A29EA126A746c70E1eAd570fdDf438E66231a](https://etherscan.io/address/0x347A29EA126A746c70E1eAd570fdDf438E66231a#code)
* **Files:**
```
BasicToken.sol
CurrentToken.sol
ERC20Basic.sol
ERC20.sol
Ownable.sol
Pausable.sol
PausableToken.sol
RBAC.sol
Roles.sol
SafeMath.sol
StandardToken.sol
```
## 3.2 Methodology
A variety of techniques, described below, were used to conduct the audit.
### 3.2.1 Code Review
The source code was manually inspected to identify potential security flaws. Code review is a useful approach for detecting security flaws, discrepancies between the specification and implementation, design improvements, and high risk areas of the system.
### 3.2.2 Dynamic Analysis
The contracts were compiled, deployed, and manually tested in a Ganache test environment. Manual analysis was used to confirm that the code operated at a functional level and to verify the exploitability of any potential security issues identified.
### 3.2.3 Automated Analysis
Tools were used to automatically detect the presence of several types of security vulnerabilities, including reentrancy, timestamp dependency bugs, and transaction-ordering dependency bugs. The static analysis results were manually analyzed to remove false-positive results. True positive results would be indicated in this report.
Static analysis tools commonly used include Slither, Securify, and MythX. Tools such as the Remix IDE, compilation output, and linters could also be used to identify potential areas of concern.
## 3.3 Risk Ratings
Each issue identified during the audit has been assigned a risk rating. The rating is determined based on the criteria outlined below.
* **High Risk** - The issue could result in a loss of funds for the contract owner or system users.
* **Medium Risk** - The issue resulted in the code specification being implemented incorrectly.
* **Low Risk** - A best practice or design issue that could affect the security of the contract.
* **Informational** - 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 system at a high level. The specification is based on the implementation in the codebase and any perceived points of conflict should be highlighted with the auditing team to determine the source of the discrepancy.
## Overview
CurrentCoin is an ERC-20 token with the following parameters.
Field | Value
---------------|-------------
Symbol | CUR
Name | CurrentCoin
Decimals | 18
Initial Supply | 100 billion
The CurrentCoin system can be paused by administrators, who are designated by the contract owner. When the system is paused, only these administrators will be able to transfer tokens. There can be any number of administrators.
Additional CurrentCoin tokens cannot be minted, and existing CurrentCoin tokens cannot be burned, fixing the total supply at the initial 100 billion. The initial supply was minted to the contract creator's address.
## Source Code
The CurrentToken smart contract has the following inheritance structure.
```
└─ CurrentToken
└─ PausableToken
├─ StandardToken
│ ├─ ERC20
│ │ └─ ERC20Basic
│ └─ BasicToken
│ └─ ERC20Basic
├─ Pausable
│ └─ Ownable
└─ RBAC
```
In addition, the `SafeMath` contract is used for all mathematical operations across the other contracts, and the `Roles` contract is used by `RBAC`.
The majority of contracts used are taken from OpenZeppelin's repository of standard contracts, with the exception of `PausableToken` and `CurrentToken`.
* `PausableToken` differs substantially from OpenZeppelin's implementation in that it allows administrators to transfer tokens while the system is paused. It also includes functionality that allows the contract owner to add and remove these administrators, which are implemented as `RBAC` roles.
* `CurrentToken` implements the ERC-20 parameters above. Upon creation, this contract will send the initial supply of tokens to the contract creator and will then pause.
<a name="section-5"></a>
# 5. Detailed Findings
The following section details the findings of the audit.
## 5.1 High Risk
No high risk issues were present at the conclusion of the review.
## 5.2 Medium Risk
No medium risk issues were present at the conclusion of the review.
## 5.3 Low Risk
No low risk issues were present at the conclusion of the review.
## 5.4 Informational
<a name="outdated-solidity-version"></a>
### 5.4.1 Outdated Solidity Version
*General*
#### Description
The contracts were written for compilation in Solidity 0.4.18. This version of Solidity was [released in October 2017](https://github.com/ethereum/solidity/releases/tag/v0.4.18) and contains a number of bugs that have been fixed in newer versions. While none of these bugs directly affected the CurrentCoin contract, it is considered best practice to use newer stable releases where these are available.
#### Remedial Action
It is recommended that the contracts be upgraded to use Solidity 0.4.26, and that the version is pinned there to prevent compilation with untested compiler versions. This can be achieved by setting the below pragma statement at the top of each contract source file:
```
pragma solidity 0.4.26;
```
When upgrading the contracts, the following optional changes can be made to bring the source code in-line with syntactical best practices in 0.4.26:
* Constructors should be declared using the keyword `constructor` instead of `function ContractName`.
* Event emissions should be preceded by the keyword `emit`.
iosiro would also recommend updating the OpenZeppelin contracts in use to version 2.0.1, as detailed in [5.4.2](#outdated-oz-contracts) below.
<a name="outdated-oz-contracts"></a>
### 5.4.2 Outdated OpenZeppelin Contracts
*General*
#### Description
As the CurrentCoin contracts were written for Solidity 0.4.18, they used version 1.6.0 of the OpenZeppelin contracts. While these outdated versions do not pose any high-risk vulnerabilities, some function names and behaviors have since changed, which may lead to CurrentCoin being incompatible with some newer dApps.
Since version 1.6.0 of OpenZeppelin, the ERC-20 `increaseApproval(...)` and `decreaseApproval(...)` functions have been renamed to `increaseAllowance(...)` and `decreaseAllowance(...)`. The functionality of `decreaseAllowance(...)` has also been amended to revert if the amount specified is greater than the remaining allowance. Finally, both functions, and `allow(...)`, have been altered to revert if called with the zero address.
The current implementation of `decreaseApproval(...)` poses a very minor risk, as discussed [here](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/437). iosiro does not consider remediation of this issue to be critical for the security of CurrentCoin.
#### Remedial Action
To bring the CurrentCoin implementation in line with more modern ERC-20 tokens, the OpenZeppelin contracts could be upgraded to [version 2.0.1](https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.1). This would necessitate upgrading the version of Solidity used to 0.4.26, as detailed in [5.4.1](#outdated-solidity-version) above. Note that this version of the OpenZeppelin contracts consolidates `ERC20`,`ERC20Basic`,`BasicToken` and `StandardToken` into a single `ERC20` contract.
### 5.4.3 Design Comments
Actions to improve the functionality and readability of the codebase are outlined below.
#### Code Clarity
*CurrentToken.CurrentToken()*
Below is the first line of the `CurrentToken` contract's constructor:
```
totalSupply_ = totalSupply_.add(INITIAL_TOTAL_SUPPLY);
```
The state variable `totalSupply_` is declared in the `BasicToken` contract but not initialized before use in this line. It will thus have a value of 0 when added to `INITIAL_TOTAL_SUPPLY`. Thus, for code clarity and to avoid using uninitialized variables, it is recommended that this line is changed to the below:
```
totalSupply_ = INITIAL_TOTAL_SUPPLY;
```
### Similarly Named Values
*PausableToken.sol*
The `RBAC` contract defines `ROLE_ADMIN` as the string `"admin"`, and the `PausableToken` contract defines `ROLE_ADMINISTRATOR` as the string `"administrator"`. By removing `ROLE_ADMINISTRATOR` and replacing its usages with `ROLE_ADMIN`, CurrentCoin could save on deployment costs and avoid needing to manually assign the administrator role contract to the contract owner after deployment, as the `RBAC` contract's constructor assigns the admin role to its owner.
Should combining these roles be undesirable, it is recommended that the name of the administrator role is changed to more clearly differentiate it from the `RBAC` admin role.
## 5.5 Closed
No issues were closed during the audit.
