CYBRO security record

All of the CYBRO tokens are sent to the `daoAddress`. This is a centralization risk because the owner of the `daoAddress` can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

In the contract `Presale` the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below.  - `updateProtocolWallet(address wallet)`: Updates the address of the protocol wallet, accessible only by the role with `DEFAULT_ADMIN_ROLE`. - `rescueFunds(IERC20 token, uint256 amount)`: Allows the rescue of funds (both native currency and ERC20 tokens) from the contract, accessible only by the role with `DEFAULT_ADMIN_ROLE`. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project In the contract `Presale` the role `OPERATOR_ROLE` has authority over the functions shown in the diagram below.  - `setStage(uint256 stageIterator_)`: Sets the current stage of the presale, accessible only by the role with `OPERATOR_ROLE`. - `updateTotalSold(uint256 amount)`: Updates the total amount of tokens sold, accessible only by the role with `OPERATOR_ROLE`. - `pause()`: Pauses the contract, halting new deposits, accessible only by the role with `OPERATOR_ROLE`. - `unpause()`: Unpauses the contract, allowing new deposits, accessible only by the role with `OPERATOR_ROLE`. Any compromise to the `OPERATOR_ROLE` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project `PresaleBSC` and `PresaleBlast` contracts inherit the `Presale` contract, which also inherited the privileged functions listed above.

No method for users or protocol to claim the incentives that Aave distributes to suppliers. E.g In Arbitrum, the aave rewards contract, currently this contract is still available for rewards claiming. However, since the contract does not include functionality to claim Aave incentives in its initial design, these rewards will forever be unclaimable. The lack of incentive claiming functionality may discourage users from using the vault contract, as they would miss out on additional earnings.

The _convertETHToUSDB() function converts ETH to USDB using a price oracle. However, for small input amounts (e.g., 1000 wei), the computation rounds down to zero due to multiple divisions in a f ixed-point arithmetic setup. If volume is too small (e.g., 1000 wei), the result rounds to 0 due to Solidity’s integer division truncating decimals.

The `_calculateAmount()` in the `Presale` and `PresaleBSC` contracts assumes that the price of tokens (`coinPrice`) is always 1 USD when `isStableToken` flag is true and that the precision (`PRECISION`) is always 6 or 18, depending on whether `STABLE_TOKEN_DECIMALS` or `TOKEN_PRECISION` is used. This assumption can lead to incorrect calculations and potential financial losses. If the price of the stable token deviates from 1 USD or if the precision is different from the assumed values, the function will calculate incorrect amounts for token transfers. This can result in users receiving more or fewer tokens than they should, potentially leading to financial discrepancies and loss of funds.

The smart contract contains functions that transfer native coins (e.g., Ether) to external addresses. These transfers are performed using the low-level `call` function, which can potentially allow reentrancy issues if the recipient is a contract that has a fallback function. An attacker could exploit this vulnerability by creating a malicious contract that has a fallback function. When the `rescueFunds` or `depositCoinTo` function transfers native coins to the malicious contract, the fallback function could be triggered, allowing the attacker to re-enter the Presale contract and potentially withdraw more funds or disrupt the contract's state. In the `rescueFunds`, `depositCoinTo`, and `depositCoin` functions, lines like `(bool success, ) = payable(msg.sender).call{value: amount}("");` transfer native coins to the sender. If the sender is a malicious contract, it could exploit this transfer to re-enter the Presale contract.

The `Presale.sol` and `PresaleBSC.sol` smart contracts contain division operations that may lead to rounding down errors. Solidity's integer division rounds towards zero, which can result in loss of precision and unintended behavior, especially in financial calculations. In functions such as `_calculateAmount` and `_purchase`, division operations are used to calculate token amounts and values. If the division results in a non-integer value, Solidity will round down the result, potentially leading to discrepancies in token allocation and financial calculations.

The timelock mechanism works this way: 1. The privilege role member (like `OPERATOR_ROLE`) calls a privileged function (like `updateProtocolWallet()`) for the first time. 2. `_timestamps` for that function is set to `block.timestamp + DEFAULT_DELAY`. 3. The privilege role member calls the function again after `DEFAULT_DELAY`. 4. The function updates the contract state and drops `_timestamps` for that function. This approach has several drawbacks: 1. The function arguments are not saved. As a result, the operator can "charge" all the timelocked functions **beforehand** with random values and bypass the waiting when execution is required. 2. Since the function arguments are not saved, the operator can demonstrate some intention, but after 12 hours execute **another** action. 3. If the function is executed before the timer passes, it refreshes the timer. This can be undesired. 4. Each timelocked function implements the same timelock logic. It is recommended to separate the timelock functionality from contract business logic. 5. `rescueFunds()` is re-enterable, so several currencies can be extracted before the `_timestamps` is zeroed.

setLendingShares() which is called be manager role does not check if pool is added or has not been removed lendingPoolAddresses by the strategist role before updating the totalLendingShares, if this happens it could affect entire protocol accounting due to additional LendingShares for pool address that are not in the lendingPoolAddresses

According to the project’s documentation, the withdrawal fee cannot be set to 100%, ensuring that users can always withdraw a portion of their funds. However, the setFees() function does not enforce this restriction, allowing the owner to set _withdrawalFee to 100%, effectively preventing users from withdrawing their assets