Audit & Report by Authio
Left White Semi CircleRight White Semi Circle

MIB Token Audit

Client
Boltsoft
Published
October 21st, 2018
Status
FINALIZED
Auditors
Alexander Wade, Alex Towle, Nikhil Sakhamuri
Authenticity

The audited contracts were sent to the Authio team in a Gist at URL: https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39

Disclaimer

This document reflects the understanding of security flaws and vulnerabilities as they are known to the Authio team, and as they relate to the reviewed project. This document makes no statements on the viability of the project, or the safety of its contracts. This audit is not intended to represent investment advice and should not be taken as such.

1. Overview

This audit serves as the official report of an ERC20 token contract written and published by MIB. The MIBToken contract seeks to be a ERC20 standard contract that provides additional control to the owner of the contract such as the ability to stop and start the token contract as well as the ability to burn tokens.

2. Introduction

2.1 Authenticity

The audited contracts were sent to the Authio team in a Gist at URL: https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39

2.2 Scope

The audit covers all of the contracts in the file provided to the Authio team. No other files were reviewed.

2.3 Methodology

This audit focuses heavily on not only inspecting the smart contracts for vulnerabilities and potential for losses in funds, but also on working closely with the Boltsoft team to scrutinize the contracts for execution of intent. The end goal of this audit is to help the team not only secure their contracts, but also to ensure their vision for the project is best represented by the project they put forward. As a result, additional concerns such as efficiency and design are included in this report as well.

2.4 Terminology

This audit categorizes vulnerabilities using the OWASP risk rating method based on impact and likelihood. Each vulnerability is given impact and vulnerability scores, which are used to give a more accurate estimation of the overall severity of a vulnerability. An additional factor in severity is the relative ease with which a vulnerability is fixed: an issue which requires extreme refactoring will be weighted higher than one with the same severity which is a quick fix.

2.5 Disclaimer

This document reflects the understanding of security flaws and vulnerabilities as they are known to the Authio team, and as they relate to the reviewed project. This document makes no statements on the viability of the project, or the safety of its contracts. This audit is not intended to represent investment advice and should not be taken as such.

3. Findings

3.1 General

The implementation presented by the Boltsoft team was for the most part high quality. There were several issues which cause the MIBToken (as of the time of this audit) to not be ERC20 compliant, which is the specification that this contract desires to meet. Additionally, some of the input validation done was redundant. Finally, the Authio team believes that the burn and burnFrom functions warrant another look by the Boltsoft team. Most of the issues that were found have very simple fixes that will not take long to implement. Suggestions made in the course of this audit attempted to remedy these issues while maintaining the integrity of the MIBToken project.

3.2 Contract Explanation

3.2.1 Function - Token

MIBToken: This contract is an ERC20 token contract that is the main focus of the project.

3.2.2 Function - Ownable

Ownable: This contract sets an owner during construction and creates the onlyOwner modifier.

3.2.3 Function - Swap Contract Registration and Deployment

MIBStop: This contract allows the owner of the contract to stop and start the contract while it is live.

3.3 Critical Severity

No critical severity issues were found.

3.4 High Severity

No high severity issues were found.

3.5 Medium Severity

transfer prevents transfers of zero value - The transfer function in MIBToken is not ERC20 compliant as it stands. From the ERC20 standard: “Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event”. This function has a require statement that causes execution to revert if value is greater than zero.

We recommend that this require statement be removed.

3.6 Low Severity

transfer prevents spending all tokens - The transfer function in MIBToken will not let users transfer all of their tokens because of the fourth require statement, which prevents users from decreasing their balance to zero by using the transfer function.

We recommend that this require statement be removed.

transfer input validation - The third require statement is unnecessary because any overflow will be prevented by the use of safe math later in the function and the value of balances[to].add(value) should be able to be zero since balance[to] can equal zero and the ERC20 standard states that transfers with value zero must be allowed. As it stands, this implementation threatens to break ERC20 compliance.

We recommend that this require statement be removed.

approve racing condition - The approve function is subject to a well known ERC20 racing condition involving the transferFrom and approve functions. The MIBToken contract seeks to be an ERC20 contract and will be vulnerable to this racing condition.

One of the suggestions to mitigate this issue is to drop approval values to zero when a change occurs. After the approval value of zero has been verified, the approval can safely be increased to the new level.

A detailed explanation of the racing condition is given here: https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit.   

3.7 Notes & Recommendations

burn - The MIBToken contract defines an internal function,_burn, which is only used in the burn function. This internal function is unnecessary, and the function logic can be implemented directly in burn.

_burn - Despite the fact that tokens are removed from the ecosystem when this function is called, the only state change is that the owner’s balance is decremented and two events are emitted. This means that all of the tokens in the ecosystem could be burned while _totalsupply will remain unchanged. A possible solution to maintain more transparency would be to increment balance[address(0)] so that users can see how many tokens are out of circulation.

burnFrom - The MIBToken contract defines a method, burnFrom, which allows the contract’s owner to drain users’ token balances, and award them to the owner.

decimals - The decimals variable can be made constant to lower gas costs.

symbol - The symbol variable can be made constant to lower gas costs.

tokenName - The tokenName variable can be made constant to lower gas costs. Additionally, the ERC20 standard states that this variable should be named name, so our suggestion would be to rename the variable name.

transferFrom - The second and third require statements in this function are unnecessary. These conditions are enforced by the SafeMath library. We recommend that these require statements be removed.

Token Getters - The ERC20 specification includes optional methods called name(), symbol(), and decimals() that should be considered as an addition to MIBToken contract.

fallback - A fallback function that reverts has the same effect as having no fallback function at all. This can be removed.

4. Documents & Resources

4.1 Line-By-Line Comments

https://github.com/authio-ethereum/Audits/tree/master/MIB

4.2 Project Code

https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39

5. Conclusion

The Authio team would like applaud the Boltsoft team on their MIBToken project. Using the suggestions mentioned, the MIBToken codebase will evolve into a strong token contract. We recommend that Boltsoft continue with the process of securing their code by posting public bug bounties and soliciting community feedback.