1
Table of contents Abstract 3 Disclaimer 3 Scope 3 Procedure 4 AS-IS overview 5 Audit overview 10 Conclusion 11 Disclaimer 12 Appendix A. Automated tools reports 12 2
Abstract In this report, we consider the security of the BonusToken, ERC20 and Game contracts. Our task is to find and describe security issues in the smart contracts of the platform. This report presents the findings of the security assessment of Customer`s smart contract and its code review conducted between January 14th, 2019 - January 17th, 2019 Disclaimer The audit does not give any warranties on the security of the code. One audit can not 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. Scope The scope of the project is BonusToken and Game smart contracts: 1. BonusToken 2. Game We have scanned this smart contracts for commonly known and more specific vulnerabilities. Here are some of the commonly known vulnerabilities that are considered (the full list includes them but is not limited to them): 3
Unsafe type inference Timestamp Dependence Reentrancy Implicit visibility level Gas Limit and Loops Transaction-Ordering Dependence Unchecked external call Unchecked math DoS with Block Gas Limit DoS with(unexpected) Throw Byte array vulnerabilities Malicious libraries Style guide violation ERC20 API violation Uninitialized state/storage/local variables Compile version not fixed Procedure 4
In our report we checked the contracts with the following parameters: Whether the contracts is secure. Whether the contracts corresponds to the documentation. Whether the contracts meets best practices in efficient use of gas, code readability. We perform our audit according to the following procedure: Automated analysis: Scanning contracts by several public available automated analysis tools such as Mythril, Slither. Manual verification all the issues found by tools Manual audit: Manual analysis smart contracts for security vulnerabilities Checking smart contracts logic and comparing it with one described in the documentation AS-IS overview BonusToken contract overview 5
BonusToken contract constructor sets: startgameaddress address of user who has rights to manage lottery. BonusToken has 2 modifiers: onlyowner check that msg.sender is owner this contract. onlygame check that msg.sender is equal to startgameaddress. tokenisavailable check that msg.sender is owner of token and nor zero address. GetToken.sol has 15 functions: setgameaddress set address who can lead lottery. buytokens - call private function _mint(). startethlottery is changing status the lottery of ether as started. starttokenslottery is changing status lottery of token as started. restartethlottery set participants array to zero clear total lottery bank and stop lottery. restarttokenslottery set participants array to zero clear total lottery bank and stop lottery. 6
updateethlotterybank is decreasing amount of lottery bank in Ether. updatetokenslotterybank is lottery bank in token. swaptokens call private function _burn(). sendtokenstoethlottery - if lottery started and amount of participants is enough call _burn() add money to lottery account and add msg.sender as participant. sendtokenstotokenslottery - if lottery started and amount of participants is enough call _burn() add money to lottery account and add msg.sender as participant. ethlotteryparticipants return array of all participants in lottery of ether. TokensLotteryParticipants return array of all participants in lottery of ether. setinvesttokenaddress - check given address as not equal to zero and set it as investtokenaddress. SetMaxLotteryParticipants set the maximum amount of participants decreasing amount of Game contract overview Game contract constructor sets: 7
startbeneficiar address of user who will receive fee from each bet. callbackgas set amount of gas for callback function. oraclize_setcustomgasprice call function to set gas price for callback. Game has 1 modifier: valideaddress check that address not zero: Game has 3 events: PlaceBet call function of bet to show data of who bet now Bet - call in callback function and show who win in game. WinLottery - call in callback function and show who win in lottery. Game.sol has 17 functions: placebet - check is msg.value more or equal to minimal bet than check the correctness of data. According to the game set chance to win and range than remember player, call random function and calculate the prize. Set the answer to the query. lottery check is function was called more than 24 hours ago than check amount of bets more than zero call startethlottery(). Move participants with balance 8
more zero to tokensholders array. Call updatelotteryranges() function set current time and call random(). sendbonustokens - check is function was called more than 24 hours ago than all players whose cash flow more or equal to 1 ether get 100 tokens. refund check is msg.sender in list who wait for prize than check is enough ether on balance of contract after that send money. refundbet if haven't send money yet and hours ago than send money to user. setoraclizegasprice call function which set gas price. setoraclizegasprice set gas limit. setbeneficiaraddress set address as user who get fee from bets. settokenaddress set address of token contract in case of change. getfunds get money from contract to owner. getbeneficiarfund owner get all money of beneficiar. callback check that msg.sender is contract of oraclize. If it is callback from bet find winner and call sendwin(). Else if it is lottery choose winner from tokensholders use random number and ranges. After bet was 24 9
that call random() till lotterystage equal 5 and than call restartethlottery to restart lottery. updatelotteryranges get array of tokensholders and make a range from their balances. validebet check data for betting for correctness. fee calculate fee for beneficiar, lottery and subtract from bet amount. newquery set new query according to data. random call function which call contract of oraclize. sendwin if enough money on contract send money else set address and amount to map of waiting for prize. deletetokensholder delete element from the end of array and move elements in array. Audit overview Critical No critical severity vulnerabilities were found. High No high severity vulnerabilities were found. 10
Medium No medium severity vulnerabilities were found. Low Not using abi.encodepacked in a contracts is bad practice. In current versions of compilers, it is recommended to use keccak256 (abi.encodepacked (result)); instead of keccak256 (_result); in Game.sol (line 226); in Game.sol (line 251) (see Appendix A pic 3 for evidence). Lowest Code style issues: No code style issues were found. Informational statements: 174 line, Contract ERC20 (BonusToken.sol) For deployment gas reduction it is recommended to use interface of token in contracts where it used, providing token address to constructor. Conclusion To summarize the audit of contracts our team found security issues from low to lowest severity. All necessary information related to the audit contains report. The contracts was checked manually and analyzed using static analysis tools. Since the detected vulnerabilities have a 11
low level as maximum, the code is considered safe and small fixes are required. Disclaimer To ensure the security of the smart contracts only one audit cannot be considered enough as audit does not give any warranties on the security of the code. We always recommend proceeding to several independent audits and a public bug bounty program. Appendix A. Automated tools reports Pic.1 Mythril BonusToken.sol and Game.sol automated report 12
Pic.2 Slither BonusToken.sol automated report Pic.3 Slither Game.sol (part1) automated report 13
Pic.4 Slither Game.sol (part2) automated report 14