APEMaster (Staking) Audit

In the APEMaster Smart-Contract were found no vulnerabilities and no backdoors, but were discovered some errors. The code was manually reviewed for all commonly known and more specific vulnerabilities.
Note: there was no pre-minting of this token and any additional minting of tokens (other than from APEMaster contract) is impossible.
So APEMaster Smart-Contract is safe for use in the main network.
Note: this audit concerns only APEMaster smart-contract, not other parts of APE project.

1. Event wrong data (medium severity):
Event ‘referralReward‘ contains 3 parameters: referrer address, user address and amount of reward. But inside of ‘_claimStaked’ function instead of user address referrer address is given again.
Note: it doesn’t concern internal logic of smart-contract, events are used to display data on the website.

2. Unused variables (medium severity):
‘safeTokenTransfer’ and ‘safeSendValue‘ functions meaning is to decrease sending amount to balance of contract if amount exceeds balance. But actually modified ‘amount’ variable is missed and initial ‘_amount‘ parameter is sent. So using both functions makes no sense.

3. Level limit inaccuracy (low severity):
There is 10 level limits (LEVEL_LIMIT) for minting tokens by different yield (LEVEL_YIELD). The sum of each limit is the maximum supply of the token (27.5M). Actually if you update pending minted amount too late the current minted amount (_mintedCurrentLevel) of each level can be more than limit.
It won’t lead to breaking the limit of total supply, but it makes logic of yields not exact.

4. False requirement (low severity):
There is requirement for the owner that he cannot stake, but he can get around this requirement by temporarily transferring ownership to other account.
Note: owner cannot take advantage from this action.

1. Excessive variable (very low severity):
There is ‘addr’ parameter to store user’s address inside of ‘User’ struct. It can be totally removed since every use of this parameter can be replaced with simple ‘msg.sender’.
2. Excessive if/else statement (very low severity):
Zero-check of ‘_referrer’ address parameter is excessive since zero address will not pass next exist-check. It can be removed.
3. Recording statistical parameters in the blockchain (very low severity):
There is 1 statistical variable ’totalReferrals’ that increases the cost of transactions and increase the amount of data stored in the blockchain:
Recommendation: use events and log this information instead of writing it to the blockchain.
Note: this comments do not affect the main functionality of the smart-contract and concern only cost of transactions.

1. Inside of ‘_mintTokens’ function ‘toMint’ variable can be modified in case to prevent exceeding of maximum supply of token, but ‘_mintedCurrentLevel’ is recorded before that.
Recommendation: move 204 line of code to 210-211.
2. Usually memory variable ‘user’ is used to fetch user’s data. But at the 262 line of code fetches ‘_users[_address].lastClaim’. Recommendation: use ‘user.lastClaim’ instead.
3. ‘unstake’ function sends token profit and staked amount to user, but leaves referral bonuses.
Recommendation: add referral bonus withdraw to ‘unstake’ function.