Read the findings of the 2022 Web3 Security Report

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

In the contract `ConfigMining.sol` the role `Manager` has authority over the functions:
- setCheckList()
- updateCheckList()

In the contract `NFTMining.sol` the role `Manager` has authority over the functions:
- setConfigMining()
- setMaxStakingTime()
- addPool()

Any compromise to the `Manager` account may allow a hacker to take advantage of this authority.

Centralization Related Risks

The function that affects the status of sensitive variables should be able to emit events.

Missing Emit Events

According to the logic of `ConfigMining`, `setCheckList()` is used to add new `miningAttributesList` and `updateCheckList` is used to update one element of `miningAttributesList`.

Missing Input Validation

The given input is missing the check for the non-zero address.

Variable `ListingID`, `listing` and `ListInfoS` were declared but never used.

Unused Variables

The linked variables are assigned only once, either during their contract-level declaration or during the `constructor`'s execution.

Mutability Specifiers Missing

According to the logic of function `checkWithdraw()`, if users want to withdraw their nft, the godTokenID they deposited cannot be 0.

If there isn't enough tokens in the contract, the validation in L315 will fail. Further, users will not be able to withdraw their staked asset.

Unable To Withdraw When Rewards is Insufficient 

The condition in L216 is not correct. According to current logic, it is impossible to enter into the for loop since the initial value of `i` will not <= 0. It means that user's `batterTokenIDList` will not be cleaned.

Incorrect Condition

What is the purpose of dividing amount by 1000 and then multiplying by 1000? Do you want to drop the last three digits?

Discussion For Function `staking()`

While if users' pending reward is greater than 0, `uss.witdrawBlock` will be updated. But update it for all cases is better.

Missing Update Withdraw Block

Since users' reward contains gain from staking, so the numbers of `userNeedReward` is consistent with users' real reward.

Inconsistent Rewards Volume

When `depost()` is called, `uss.startBlock` will be updated. The mining reward is related to the number of pledged blocks, so when the user makes an additional deposit, the reward from the previous deposit is lost.

Additional Deposits Will Result In Lost Rewards

According to the logic, the `checkWithdraw()` only limits the activity has ended and the user has not withdrawn the pledged `BattleNFT`, but it cannot limit the receipt of the reward. Since `withdrawReward()` can be called externally, the user can call the function without limit until the reward balance in the contract is low. 

Rewards Can Be Withdrawn Multiple Times

The contract is serving as the underlying entity to interact with third party protocols. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Third Party Dependencies

In `pendingreward()`, the function does not check whether the user has made the deposit. If the user has no deposit, the reward will be calculated from block 0. Although it will not affect the actual reward, it may be misleading.

MGA-Prometheus

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

17

0

5

0

12