Cyberconnect - staking pool

The `withdraw()` allows users to withdraw assets from the contract. However, it does not validate whether the assets being withdrawn are part of the `assetWhitelist`. This oversight could lead to the transfer of unapproved assets or potentially expose the contract to reentrancy attacks if the `safeTransfer` function interacts with a malicious contract.

The contract uses a generic `assetWhitelist` mapping to control which assets are allowed for bridging. However, this design does not account for the possibility that different bridges may have different requirements or risk profiles for asset whitelisting. The current implementation of the `setAssetWhitelist()` and the `_bridge` function does not provide a way to specify which assets are whitelisted for which bridges.

The `withdraw`, `bridge`, and `bridgeWithSig` functions lack the `whenNotPaused` modifier, which means these functions can still be called when the contract is paused. This could lead to potential risks, especially in emergency situations where pausing the contract is necessary to prevent further transactions.

When a loop allows an arbitrary number of iterations or accesses state variables in its body, the function may run out of gas and revert the transaction. ```solidity=106 for (uint256 i = 0; i < assets.length; i++) { ``` Function `CyberStakingPool.withdraw` contains a loop and its loop condition depends on parameters: `assets`.

The `Deposit` event is emitted both in the `deposit` function for ERC20 token deposits and in the `depositETH` function for native ETH deposits. This reuse of the event for different deposit types could lead to confusion and complications in off-chain monitoring systems that rely on event logs to distinguish between the two types of deposits. An off-chain monitoring system is set up to track deposits into the contract. It might incorrectly interpret a `Deposit` event from a `depositETH` call as a regular ERC20 token deposit, leading to inaccurate tracking of the contract's activity.