CYBRO

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.

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.

The smart contract uses a third-party oracle (`COIN_PRICE_FEED`) to fetch the current coin price for calculating the amount of tokens to be transferred during deposits. This reliance on an external data source introduces a point of failure and potential security risks, such as manipulation of the oracle data. For example: 1. An attacker gains control over the oracle or manipulates the data feed. 2. The attacker alters the coin price data returned by the oracle. 3. Users of the contract receive an incorrect amount of tokens for their deposits, leading to financial losses. This will impact sensitive variable values in the contract, for example, in `_purchase` function, according to `uint256 usdInEth = 1 ether / coinPrice;`, the value of `usdInEth` will be directly related to the value of `coinPrice`, which is fetched from the oracle

`PresaleBSC` is supposed to be deployed in BSC chain. It overrides `_depositChecksAndEffects()` and `_depositInteractions()`, however, the code is identical and can be omitted. The code can use `token.decimals()` and `COIN_PRICE_FEED.decimals()` to make it chain independent and ensure the calculations will be correct. In case the chain dependence can't be avoided `block.chainId` can be used to branch the execution. The stablecoin address can be provided as an argument to the deposit function and checked in the code that it is supported. Deploying different versions to different chains can lead to accidental mistakes.

The smart contract constructors for `Presale` and `PresaleBlast` do not validate that the addresses provided for the token contracts (`usdcToken`, `usdtToken`, `usdbToken`, and `wethToken`) are not the zero address. This lack of validation could lead to undefined behavior if any of these addresses are set to the zero address, as the zero address is not a valid contract address.

```solidity=54 stages.push(StageData(1e6, 75e5)); stages.push(StageData(15e5, 1e7)); stages.push(StageData(2e6, 175e5)); stages.push(StageData(25e5, 28e6)); ``` Numbers with different decimals are hard to read. Consider using the same, like: ```solidity=54 stages.push(StageData(1e6, 7.5e6)); stages.push(StageData(1.5e6, 10e6)); stages.push(StageData(2e6, 17.5e6)); stages.push(StageData(2.5e6, 28e6)); ``` ```solidity=77 _timestamps[0xe308a099] = 0; ``` `this.updateProtocolWallet.selector` can be used instead of the magic number.

The emitted event `AmountAndUSD` in the `_calculateAmount` function does not consider the precision of the calculated amount. This can lead to misunderstandings when interpreting the event data, as the values might not accurately represent the intended amounts due to the lack of precision adjustment. When the `_calculateAmount` function is called, it emits the `AmountAndUSD` event with `expectedAmount` and `coinPrice`. However, the `expectedAmount` is not adjusted for precision before being emitted. This can result in the event displaying a value that is not correctly scaled according to the token's decimals.