BEBE security record

### ValidatorSmartContract In the contract `ValidatorSmartContract`, the role `RootValidator` has authority over the functions listed below. - approveValidator() - disapproveValidator() - revokeValidator() - addRootValidator() - removeRootValidator() - queueAction() - executeAction() - cancelAction() If multiple `RootValidator` accounts are compromised to meet multi-sign threshold, the hacker could exploit this authority to perform operations like approving, disapproving, or revoking on normal validators at will, adding or removing the root validator. The role `RootValidator` also has the authority to queue the execution of the following functions and schedule these functions to be executed after 48 hours. - executeEmergencyWithdraw() - changeState() If multiple `RootValidator` accounts are compromised to meet the multi-sign threshold, the hacker could exploit this authority to schedule operations like withdrawing all native tokens to the emergency wallet or changing the state of the contract.

Signed messages are not properly verified with the current chain ID and the address of the contract, thus allowing attackers to perform replay attacks across chains or contracts (from the old version to the new version). Especially if the team plans to deploy contracts on multiple chains or if the team has deployed multiple versions of contracts, the signature and message hash can be reused in the future.

Both the `revokeValidator` function and the `initiateWithdrawal` function will remove the validator from the active set; whichever transaction is mined first “wins.” The second transaction will check `!info.isActive` and will revert with a `NotActiveValidatorError()`. ```solidity function revokeValidator(address validator) external onlyAdmin nonZeroAddress(validator) whenNotPaused { ... if (!info.isActive) revert NotActiveValidatorError(); ... revokedValidators[validator] = true; ... delete validatorInfo[validator]; ... } function initiateWithdrawal() external whenNotPaused whenNotEmergency { if (revokedValidators[msg.sender]) revert RevokedValidatorError(); ... if (!info.isActive) revert NotActiveValidatorError(); ... delete validatorInfo[msg.sender]; ... } ``` If the `revokeValidator` is used to permanently remove a validator (for malicious behavior or policy violation), this could be an issue since the validator can see the admin’s transaction in the mempool, they can “front‐run” the admin by calling `initiateWithdrawal` with a higher gas price (or via a private/Flashbots/MEV transaction). Once the validator’s transaction is included first, `info.isActive` becomes false, so the subsequent `revokeValidator` from the admin will revert. As a result, the validator escapes without the “revoked” label and they could rejoin in the future if they want.

If there are two or more time-locked actions that depend on the contract’s state, the order in which they are executed can lead to different results. One action can invalidate the other if the state is changed first. Consider the following example: - Action A: `changeState(ContractState.ACTIVE)` - Action B: `executeEmergencyWithdraw()` When the contract’s `contractState` is `EMERGENCY`: - If Action B (withdraw) is executed first, it will succeed because the contract is still in an `EMERGENCY` state. - If Action A (change state to `ACTIVE`) is executed first, Action B will revert on its subsequent execution attempt because the contract would no longer be in an `EMERGENCY` state. In other words, the final outcome depends on the order in which these timelocked actions are executed—a detail not enforced on-chain.

In the contract's constructor, the initial validators are registered with a `stake` value of `0`. Normally, in a proof-of-stake (PoS) consensus mechanism, validators are selected for block production based on the proportion of their staked amount relative to the total staked amount. However, the current implementation assigns initial validators with no staked funds. ```solidity for (uint i = 0; i < length; i++) { ... validatorInfo[validator] = ValidatorInfo({ stake: 0, index: uint32(i), registeredTime: uint32(block.timestamp), activatedTime: uint32(block.timestamp), isActive: true, isWaiting: false, ownerAddress: validator }); } ``` This raises the concern of whether these initial validators are treated differently by the consensus algorithm. This may undermine the security assumptions of a PoS system and initial validators might have an unfair advantage over later participants who are required to meet the `requiredStake` condition when registering.

The function `claimIncome()` allows users to claim their percentage of mined tokens the day after they are mined. However, the timestamp at which a user is able to be claimed will differ, and those who stake in a block whose `block.timestamp` is a multiple of `SECONDS_PER_DAY` will be able to claim before any other users. In general, the lower the value of the timestamp of the block when staking modulo `SECONDS_PER_DAY`, the sooner they will be able to claim tokens. This creates an unfair advantage as users who stake at a more advantageous `block.timestamp` will be able to sell tokens before other users.

The lines cited above set variables to their default value. The keyword `delete` can be used in their place as it more closely matches the semantics of the logic.

The function `importStake()` can only be called by the owner and is designed to be able to add users stakes without the need for the user to transfer tokens or call `stake()`. However, this function will update the stored `totalPower` for the input `stakeTime` date, which in some cases can cause rewards to be misallocated. If the `stakeTime` is for a date that has not yet been mined and no stakes are made for that date when it is reached, then it will cause `_incomePools[incomeDay].totalPower` to be nonzero, so that the function `confirmAddIncomePool()` will not compute the total power for that income day and thus allocate funds based only on the stakes added via `importStake()`, when it should also include the previous stakes in the calculation. If the `stakeTime` is for a date where some users have already claimed their income, then it will add to the `totalPower`, however, as some amount was already claimed this will cause more than the `poolAmount` to be allocated so that the last users will be unable to claim all tokens they are entitled to. In addition, there are other cases where inputs may provide incorrect rewards.

### BEBEStakeManager The function `importStake()` does not perform the following checks: - It does not check `_stakeEnabled` is true. This may be by design as it is a privileged function, however, we would like to ensure it aligns with the design intent. - It does not check if `_userActiveStake[staker[i]]` is already staked. This can override a users stake unexpectedly. - It does not check that the input `staker[i]` is not `address(0)`. If it is set to the zero address accidentally it will cause income to be unable to be claimed. - It does not check that the `amount[i]` are greater than or equal to the `MINIMUM_STAKE` and less than or equal to the `MAXIMUM_STAKE`. This can allow any amount to be staked. - It does not check the length of the `staker`, `stakeTime`, and `amount` arrays are the same. If the lengths differ, then the inputs are likely incorrect and may cause incorrect values to be set.

Functions that update state variables should emit relevant events as notifications.