BEBE security record

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.

Within the `ValidatorSmartContract`, the `_requireValidSignatures` function contains a logic bug involving the line: ```solidity uint16 validatorBit = uint16(1 << info.index); ``` This line attempts to track which root validators have signed a particular action using a 16-bit bitmap. The contract stores a list of validators in the `validators` array. Each validator has an associated `ValidatorInfo` struct, which includes a `uint16` index. This index is simply the validator’s position in the `validators` array. When a new root validator is added (via `addRootValidator`), `info.index` is set to the new `validators.length - 1`. This value can be between 0 and 254. Because a validator’s `info.index` can exceed 15, shifting `1 << info.index` and then casting to `uint16` truncates values above 15 bits to 0. Consequently, potential double-signature from two different root validators both above index 15 could map to 0 in the mask, so the code might not detect that they are distinct signers. (Though in practice it sees 0 for both and just checks `signersBitmap & 0 == 0`, so the second signature is also “accepted” but increments approvals incorrectly—leading to under- or over-counting.) This issue directly compromises the core security guarantee of multi-signature authorization among root validators. An action may fail to be authorized, or the contract may count incorrect signers.

### 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 `queueAction` function allows the root validator to initiate `TimedAction` data for subsequent `executeAction`. The `actionType` in `queueAction` can be set any value, which is different from other functions, such as `APPROVE_VALIDATOR` in `approveValidator`. ```solidity=373 function queueAction( string memory actionId, string memory actionType, uint256 timeoutBlock, address targetAddress, ContractState newState, bytes[] memory signatures, bytes calldata _data ) external nonReentrant onlyRootValidator { if (_usedActionIds[actionId]) revert DuplicateActionError(); _usedActionIds[actionId] = true; _requireValidSignatures( actionId, actionType, timeoutBlock, targetAddress, newState, signatures ); ... } ``` If a one root validator disagrees with an `actionId` for functions such as `approveValidator` or `removeRootValidator`, that validator can front-run the function and consume the `actionId` in the `queueAction`. Consequently, functions like `approveValidator` or `removeRootValidator` will be reverted. This allows the root validator to veto an `actionId` easily.

In the `ValidatorSmartContract`, the functions that require multiple signatures (e.g., `approveValidator`, `disapproveValidator`, `addRootValidator`, `removeRootValidator`, `revokeValidator`, and `changeState`) only include `actionId` and `actionType` in the signed message. They do not include critical parameters such as the target `validator` address or the new contract `state`. This allows anyone who holds valid signatures for a certain (`actionId`, `actionType`) pair to reuse those signatures to carry out the same action type but on any arbitrary parameter.

In the `queueAction` function, the `_data` parameter can be set to any value without validation, which may threaten the system in the subsequent `executeAction`. For example, the `data` for `changeState` can be replaced by the `executeEmergencyWithdraw`.

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.