Disclaimer

The audit does not give any warranties on the security of the code. One audit cannot be considered enough. We always recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts. Besides, security audit is not an investment advice.

Summary

In this report, we considered the security of Faireum smart contracts. We performed our audit according to the procedure described below.

The audit showed no critical issues. However, one medium severity and a number of low severity issues were found. They do not endanger project security. Nevertheless, we highly recommend addressing them.

General recommendations

The contracts code is of good quality. The contracts code does not contain issues that endanger project security. However, we recommend covering Code with tests, fixing Documentation mismatch, and removing Redundant code.

In addition, if the developers decide to improve the code, we recommend following best practices for Pragmas version. However, these issues are minor and do not influence code operation.

Procedure

In our audit, we consider the following crucial features of the smart contract code:

Whether the code is secure Whether the code corresponds to the documentation (including whitepaper) Whether the code meets best practices in efficient use of gas, code readability, etc.

We perform our audit according to the following procedure:

Automated analysis

we scan project’s smart contracts with our own Solidity static code analyzer SmartCheck

we scan project’s smart contracts with several publicly available automated Solidity analysis tools such as Remix, and Solhint

we manually verify (reject or confirm) all the issues found by tools

Manual audit

we manually analyze smart contracts for security vulnerabilities

we check smart contracts logic and compare it with the one described in the whitepaper

we check ERC20 compliance

we run tests and check code coverage

Report

we reflect all the gathered information in the report

Checked vulnerabilities

We have scanned BlockState smart contracts for commonly known and more specific vulnerabilities. Here are some of the commonly known vulnerabilities that we considered (the full list includes them but is not limited to them):

Project overview

Project description

In our analysis we consider Faireum whitepaper (“Faireum_whitepaper2.0_En.pdf”, sha1sum: 630f7cd253fa9e61f56e0b51e777857bb943b6da) and smart contracts code (“FaireumToken.sol”, sha1sum: 637e2aa0797f95d5853cf4f3c692a36853977c03).

The latest version of the code

After initial audit, the customer applied fixes and updated the code to the latest version(“FaireumToken-v1.1.zip”, sha1sum: 8712ae10b21faff29f8435de7e28dcda8dcc2e03).

Project architecture

For the audit, we were provided with the truffle project. The project is an npm package and includes tests.

The project successfully compiles with truffle compile command

command The project successfully passes all the tests

The total LOC of audited Solidity sources is 273.

Automated analysis

We used several publicly available automated Solidity analysis tools. All the issues found by tools were manually checked (rejected or confirmed). Cases when these issues lead to actual bugs or vulnerabilities are described in the next section.

Manual analysis

The contracts were completely manually analyzed, their logic was checked and compared with the one described in the documentation. Besides, the results of the automated analysis were manually verified. All confirmed issues are described below.

Critical issues (not found)

Critical issues seriously endanger smart contracts security. We highly recommend fixing them.

The audit showed no critical issues.

Medium severity issues (fixed)

Medium issues can influence smart contracts operation in current implementation. We highly recommend addressing them.

No tests and deployment script (fixed)

The provided code does not contain tests. Testing is crucial for code security and audit does not replace tests in any way.

We highly recommend both covering the code with tests and making sure that the test coverage is sufficient.

There is also no deployment script. However, the contracts deployment does not seem trivial. Bugs and vulnerabilities often appear in deployment scripts and severely endanger system’s security.

We highly recommend developing and testing deployment scripts very carefully.

The issue has been fixed by the developers and is not present in the latest version of the code.

Low severity issues (fixed)

Low severity issues can influence smart contracts operation in future versions of code. We recommend taking them into account.

Documentation mismatch (fixed)

There is a discrepancy between the smart contracts code and the whitepaper: According to the documentation (“Faireum_whitepaper2.0_En.pdf”, page 35):

Team/Developer/Advisor: Locked for a minimum of 12 months and followed by 1 to 2 years vesting schedule to the long-term benefit of the team/developer/advisor.

However, half of the tokens locked for 6 months and another half for a year in the code.

function lockTeamTokens(address _beneficiary, uint256 _tokensAmount) public onlyAdmin {

uint256 _half = _tokensAmount.div(2);

_lockTokens(address(teamAdvisorsTokensVault), false, _beneficiary, _half);

_lockTokens(address(teamAdvisorsTokensVault), true, _beneficiary, _half);

}

We recommend either changing contracts’ functionality so that it matches the whitepaper or modifying the whitepaper in order to avoid any discrepancies.

The issue has been fixed by the developers and is not present in the latest version of the code.

Redundant code (fixed)

SafeERC20 library at FaireumToken.sol, lines 357–369 is redundant, as it is not used in the project.

We highly recommend removing redundant code in order to improve code readability and transparency and decrease cost of deployment and execution.

The issue has been fixed by the developers and is not present in the latest version of the code.

Pragma version (fixed)

Solidity source files indicate the versions of the compiler they can be compiled with. Example:

pragma solidity ^0.4.24; // bad: compiles w 0.4.24 and above

pragma solidity 0.4.24; // good: compiles w 0.4.24 only

We recommend following the latter example, as future compiler versions may handle certain language constructions in a way the developer did not foresee. Besides, we recommend using compiler version 0.4.25. Moreover, new version of compiler (0.5.2 at the moment) is available and contains several important changes. In order to update your contracts to compiler version 0.5.2 the developers should follow solidity documentation.

The issue has been fixed by the developers and is not present in the latest version of the code.

Notes

ERC20 approve

There is ERC20 approve issue: changing the approved amount from a nonzero value to another nonzero value allows a double spending with a front-running attack.

We recommend instructing users to follow one of two ways:

not to use approve() function directly and to use increaseApproval() / decreaseApproval() functions instead

function directly and to use / functions instead to change the approved amount to 0 , wait for the transaction to be mined, and then to change the approved amount to the desired value.