BEBE

The functions `addIncomePool()` and `confirmAddIncomePool()` do not have any access restriction and can be called by anyone. This can allow a attacker to call these with an `incomeDate` that would be used by the `BEBEMiningManager`. By calling these before the `BEBEMiningManager` it will cause all calls to `mine()` in the `BEBEMiningManager` to revert once the `_nextMiningDate` reaches the `incomeDate` used by the attacker. If this is done after the `BEBEMiningManager` has mined some amount of tokens, then `_nextMiningDate` will no longer be able to be updated. This will make it impossible for any further funds to be mined by the `BEBEMiningManager` and require a new contract to be deployed. The need to deploy a new contract for users to interact with would cause damage to the reputation of the protocol and prevent users from having access to funds at the expected time.

### GameStakerManager In the contract `GameStakerManager` the role `_owner` has authority over the function `setStakeEnabled()`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the `_stakeEnabled` to true to enable staking when it is not intended to be enabled or set it to false to cause a denial of service. In addition they can transfer ownership to an account they have the sole control over or renounce the ownership so that it cannot be recovered. --- ### BEBEMiningManager In the contract `BEBEMiningManager` the role `_owner` has authority over the following functions: - `setMiningEnabled()` - `setStartMiningDate()` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and do the following: - Set the `_startMiningDate` to any date provided `mine()` has not successfully been called yet. An attacker can use this to cause a denial of service and require the contract to be redeployed or can make it so that mining is started sooner than expected so that they receive greater rewards. - Enable or disable mining. An attacker can use this to cause a denial of service and require the contract to be redeployed or can make it so that mining is started sooner than expected so that they receive greater rewards. In addition they can transfer ownership to an account they have the sole control over or renounce the ownership so that it cannot be recovered. --- ### BEBEStakeManager In the contract `BEBEStakeManager` the role `_owner` has authority over the following functions: - `setMiningManager()` - `setStakeEnabled()` - `importStake()` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and do the following: - Call `setStakeEnabled()` to enable staking when it is not intended to be enabled or to disable it to cause a denial of service. - Call `importStake()` to stake themselves for a large amount in order to capture all rewards for themselves or call it on accounts that already have stakes with a smaller staked amount in order to make it so they receive less income than they should be entitled to. In addition, `importStake()` may be called with unexpected inputs causing a misallocation of income. More details on this can be found in the finding **`importStake()` Can Cause Misallocation Of income** - Call `setMiningManager()` to set the mining manager to a malicious contract to take advantage of the privileges outlined below. In addition they can transfer ownership to an account they have the sole control over or renounce the ownership so that it cannot be recovered. --- In the contract `BEBEStakeManager` the role `_miningManager` has authority over the following functions: - `updateIncomePool()` Any compromise to the `_miningManager` account may allow the hacker to take advantage of this authority and either perform a denial of service by not calling the update income pool function or to update the income pool without transferring funds so that some users will be unable to claim their allocated tokens. In the worst case scenario an attacker can call this function with a large amount so that they can claim all tokens held in the contract for themselves.

If the token `_bebe` utilizes hooks or makes an external call during transfer that an attacker can use for reentrancy, then an attacker can utilize it to continually call `releaseStake()` to steal all `_bebe` tokens held by the contract. It should be noted that in other contracts calls to `_bebe` may also be used for reentrancy if they make an external call that can be used by an attacker.

The function `computeTotalPower()` iterates through all stakes to determine the amount that was staked prior to the input `incomeDay`. However, if there have been no stakes for the day during a mining, then `mine()` will call `computeTotalPower()`. It is possible for the number of stakers to be so large that this will cause the call to `mine()` to exceed the block gas limit. There is no method to unstake, so that this will prevent any further tokens from being mined and distributed as income. Note, that the removal of the minimum stake increases the likelihood of an attacker utilizing this to cause a denial of service. In particular, an attacker could stake 1 token with different accounts in order to increase the amount of stakes so that it is high enough that calls to `mine()` for a day where there are no stakes would exceed the block gas limit. As only 1 token needs to be staked, this decreases the cost of the attack significantly. However, this requires thousands of stakes, so the cost to the attacker will be high making this attack less likely. In addition, considering the large amount of stakes required it is unlikely to be reached naturally so we give this a *Medium* severity.

The comment above the function `getBonusMultiple()` states that the expected output should range between 0 and 12. However, to be a valid duration, the duration must be less than or equal to 360. Thus the output of this function is less than or equal to `360/30/10 = 1`, so that it will only return 0 or 1. This can result in users not receiving the bonus that they should be entitled to. However, as the use of the `bonusMultiple` is not clear within the scope of this audit we cannot be sure of this and we give this a *Medium* severity.

The function `isValidStakeDuration()` is used to determine if a users input stake duration should be allowed. As the comment above the function states, the intended supported durations should be "1 for 1 day, and multiples of 30 for monthly duration until 12 months". However, the logic will also return true for a duration of zero. This is because the function uses the logic: ```solidity return (duration == 1 || (duration <= 360 && duration % 30 == 0)); ``` And `0 <= 360` and `0 % 30 == 0`. Considering that both a duration of 1 and a duration of 0 would give the same bonus multiple, it is possible that this may allow a user who staked and released their stake in the same transaction to receive the same amount of rewards as a user who staked their tokens for 1 day. However, as the use of the `bonusMultiple` is not clear within the scope of this audit we cannot be sure of this and we give this a *Medium* severity.

The function `mine()` transfers tokens to the `BEBEStakeManager` manager when it is called. This amount is then stored in the `_incomePools[incomeDay].poolAmount` to distribute proportionally to users who have staked in the contract. However, if there are no stakes in the contract for that day, then this amount will not be allocated to any users and will be locked in the contract.

The function `claimIncome()` iterates through a for loop of all mining dates from the stored `nextClaimDate` of the stake to the `_lastPoolProcessDate`. However, `mine()` will be able to be called over 200,000 times before it distributes its 9.5 trillion tokens. In the extreme scenario a user may never claim their tokens until after all tokens are mined, in which case the for-loop will iterate over 200,000 times which would cause the gas cost of the transaction to exceed the block gas limit and revert. In general, if a user goes for too long without calling `claimIncome()`, the for-loop may require iterating enough times that it will exceed the block gas-limit. In these scenarios the user will be unable to claim their income.

The `_startMiningDate` in the `BEBEMiningManager` contract is designed to be indicate when the first call to `mine()` can be made. It is set to any value in the `constructor()` and can be set to any value via `setStartMiningDate()` as long as `mine()` has not yet been successfully called. The `_startMiningDate` in the `BEBEStakeManager` contract is used to determine the first date that `mine()` should be called so that it does not check that the previous day has had its income set. It is set to any value in the `constructor()` and can be set to any value via `setStartMiningDate()`. These values are intended to match. For example if the `_startMiningDate` in the `BEBEStakeManager` is a timestamp of a day prior to the `BEBEStakeManager` of the `BEBEMiningManager`, then calls to `mine()` will revert as the check that the previous days are populated will not pass.

The reward mechanism involving `totalPower` and storing the income for each `incomeDate` is complex and creates many fringe cases that must be handled carefully and can be hard to implement. Many findings in this report are related to this reward mechanism, so it may be beneficial to explore alternative mechanisms that are easier to implement and maintain.