Chancer - Audit

The function `rescueERC20()` can be called to transfer any ERC20 tokens to any address. According to the function name, this function is supposed to send trapped ERC20 tokens. Hence a validation is necessary to prevent the owner transfer the sale token balance of CHRPresale contract to an arbitrary user: `_tokenAddress != saleToken`.

In the contract CHRToken, the role `owner` has the authority over the following function: - `mint()` Any compromise to the `owner` account may allow the hacker to take advantage of this and mint tokens.

In line 198, the `amount` is multiplied by 1e18. Consequently, the auditors presume that the input parameters `_amount` used in both `buyWithBnb` and `buyWithBUSD` functions, also lack decimal places. This particular design choice gives rise to an issue in the price calculation process. The variable `priceInBUSD` is computed without considering any decimals and subsequently utilized in the calculation of `priceInBNB`. Notably, the `priceInBNB` solely undergoes multiplication by 1e8 and thus lacks decimal places altogether. Consequently, if the value of `priceInBNB` does not exceed 1 BNB, it will become 0 since it is type uint256. Furthermore, in line 166, the calculation involves subtracting `priceInBNB` from `msg.value`. Considering that the `msg.value` contains 18 decimal places, this calculation would yield an incorrect result. Additionally, the comments in lines 227-228 refers that `priceInBNB` has a decimal of 18 and `priceInBUSD` has a decimal of 6, which are inconsistent with the implementation. `priceInBUSD` also shouldn't have a decimal of 6.

The comments for `_limitPerStage ` and `_pricePerStage` are not correct.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

There are no limits on `claimStartTime` and `saleEndTime` setting in the constructor, function `configureSaleTimeframe`, and function `configureClaim`. Due to the lack of documentation, the auditors are not sure if the system design allows the `claimStartTime` to be smaller than `saleEndTime`. If users are allowed to buy tokens after `claimStartTime`, we recommend replacing the `hasClaimed[_msgSender()]` check to `purchasedTokens[_msgSender()] = 0` in function `claim`. Otherwise, we recommend adding checks to ensure `saleEndTime` will always be smaller than `claimStartTime`.