Date Completed: March 5, 2021
This report reviews the Bitcoinus Smart Contract, which was launched in January 2018. The preliminary review was conducted by the CTO and post edited by Betty Martinez and Zhihui Zheng. We conducted static code analyses, symbolic execution enhanced by artificial intelligence, and a detailed analysis system design.
Our review focused on the smart contract in repository below at the specified commit.
The exact file analyzed can be found in the Appendix.
Evaluate the system design.
Identify known vulnerabilities common to all smart contracts.
Conduct fuzzing with AI tools to trigger unexpected code executions.
After a thorough analysis, our team suggested four recommendations and discovered no major issues in the Bitcoinus Smart Contract.
Bitcoinus is a blockchain payment platform that allows merchants to accept payments in cryptocurrencies. Furthermore, this system uses the Bitcoinus Token. The Bitcoinus Token code is composed of three main components, as shown in the diagram below.
The ERC20 Standard implemented in the
ERC20 Abstract Class is a standardized set of functions to facilitate the transfer, approval, and allowance of a token during a transaction. This is a widely accepted standard that allows integration with other smart contracts, wallets, or marketplaces.
The inherited Ownable Class serves a basic access control mechanism. There is a specific account identified by the hash address, which acts as the owner and is granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract.
Arithmetic operations in Solidity wrap on overflow. This can easily result in bugs because programmers usually assume that an overflow raises an error, which is the standard behavior in high-level programming languages. The
SafeMath Library restores this intuition by reverting the transaction when an operation overflows.
The Bitcoinus code base was well-commented and had adequate testcases. Having that said, we recommend the following improvements.
Updating the contract to use Solidity version 0.8 and above would reduce the amount of gas consumed per transaction since integer overflow errors could be detected by the compiler itself. This modification would also reduce the contract size and increase readability since the
SafeMath Library would no longer be needed.
The version of SafeMath utilized by this contract uses assert instead of require, which consumes more gas when catching errors. Both functions will reverse the transaction on the blockchain; however, assert uses up all of the remaining gas while require does not. Therefore, one may consider modifying this contract to validate user inputs with the require function.
This contract is using a floating pragma. We recommend locking the pragma at a specific compiler version to help ensure contracts are not deployed using a different compiler version which may introduce bugs due to unexpected functionality.
pragma solidity ^0.4.18; // Floating Pragma
pragma solidity 0.4.18; // Locked Pragma
public functions in Solidity make a copy of arguments in memory, unlike
external functions, which reference arguments directly in the preexisting stack, using an external modifier, instead of public, for functions which are never used internally reduces gas consumption.
There were no major issues discovered in the Bitcoinus Token.
This audit covered the following file from the Bitcoinus Repository at commit 318aee6aa34e1727a370556f4eec841e539080c8:
|File Name||File Path|
This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale, or any other product, service, or other assets.
No third party should rely on this Report in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other assets. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty.