SidusPad security record

In the contract `DCBCrowdfunding`, - the role `investment` has authority over the following functions: - `setParams`: Sets the state variables. - `setToken`: Sets the sale token address. - the role `layerZero` and `tierMigratorAddr` have authority over the following function: - `registerForAllocation`: Registers user for allocation. - the role `manager` has authority over the following function: - `registerByManager`: Registers users in bulk. In the contract `DCBPlatformVesting`, - the role `factory` has authority over the following functions: - `setCrowdFundingParams`: Sets the state variables for the crowdfunding contract. - `setVestingParams`: Sets the state variables for the vesting contract. - `setToken`: Sets the sale token. - `claimDistribution`: Claims the releasable vested tokens. - `rescueTokens`: Transfers the vested tokens to the `_receiver` account. - the role `owner` has authority over the following function: - `transferOwnership`: Transfers the ownership to `newOwner`. - `setTokenClaimWhitelist`: Sets the whitelist for token claim contract. - `setCrowdfundingWhitelist`: Sets the whitelist for the crowdfunding contract. - `renounceOwnership`: Leaves the contract without owner. - the role `innovator` has authority over the following function: - `claimRaisedFunds`: Claims the raised funds from this contract. In the contract `DCBPowerBoost`, - the role `owner` has authority over the following functions: - `setWhitelist`: Sets the status of `_address` within the whitelist. - `renounceOwnership`: Leaves the contract without owner. - `transferOwnership`: Transfers ownership of the contract to a new account (`newOwner`). - the role `whitelisted` has authority over the following functions: - `deposit`: Increases the user's deposit balance. - `withdraw`: Decreases the user's deposit balance. In the contract `DCBTierMigrator`, - the role `manager` has authority over the following functions: - `addNewEvent`: Adds an new event into the `events` list. - `setEvent`: Updates the element at index `_eventId` in the `events` array. - `setHasRegistered`: Sets the status of `hasRegistered` in bulk. - `setContracts`: Sets the `endpoint`, `tiers`, `walletStore` contract addresses. - `setNativeChainId`: Sets the native chain id. - `setMinShareForUser`: Sets the minimum share. - the role `DEFAULT_ADMIN_ROLE` has authority over the following function: - `setManagerRole`: Grants/Revokes the manager role. In the contract `DCBTiers`, the role `owner` has authority over the following functions: - `addTier`: Adds new tiers. - `setTier`: Updates a given tier. - `setBoostValues`: Sets the `boostValues` mapping value. - `setLegacyContracts`: Sets the external dependency contracts. - `setNewContracts`: Sets the `multiAssetStakingContract`, `compounderContract`, and `liquidityLocker` contract addresses. - `renounceOwnership`: Leaves the contract without owner. - `transferOwnership`: Transfers ownership of the contract to a new account (`newOwner`). In the contract `DCBTokenClaim`, - the role `_investment` has authority over the following functions: - `setParams`: Sets the parameters for the claim. - `setToken`: Sets the token to be used for claim. - the role `layerZero` and `tierMigratorAddr` have authority over the following function: - `registerForAllocation`: Registers user for allocation. - the role `manager` has authority over the following function: - `registerByManager`: Registers users in bulk. - `setMinTierForClaim`: Sets the minimum tier required for claim. (This function has been removed from the codebase in commit [5335bf0956a2df0d626e54f59b8db0d5ddb49e25](https://github.com/Decubate-com/platform-contracts/commit/5335bf0956a2df0d626e54f59b8db0d5ddb49e25)). In the contract `Tiers`, - the role `owner` has authority over the following functions: - `addTier`: Adds new tiers. - `setTier`: Updates a given tier. - `setBoostValues`: Sets the `boostValues` mapping value. - `setContracts`: Set the external dependency contracts. - the role `DEFAULT_ADMIN_ROLE` has authority over the following function: - `setManagerRole`: Grants/Revokes the manager role. (This function has been removed from the codebase in commit [5335bf0956a2df0d626e54f59b8db0d5ddb49e25](https://github.com/Decubate-com/platform-contracts/commit/5335bf0956a2df0d626e54f59b8db0d5ddb49e25)). Any compromise of the privileged accounts may allow a hacker to take advantage of this authority to modify sensitive state variables, transfer funds, and ultimately damage the entire project, causing significant financial loss.

The listed contracts inherit upgradeable contracts, indicating that they are part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise of the privileged account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract.

The `setParams` and `setToken` functions are exclusively controlled by the `investment` role, which is responsible for updating crucial state variables like `saleToken`, `dcbAgreement.totalTokenOnSale`, `dcbAgreement.hardcap`, `cbAgreement.startDate`, and `dcbAgreement.minTier`. These variables are pivotal to the project's integrity. Unauthorized modifications could severely impact certain functionalities, potentially eroding user trust. For instance, within the `fundAgreement` function, users can deposit tokens to receive rewards based on the duration of their deposit. However, any changes to `saleToken` or `dcbAgreement.totalTokenOnSale` that precede a user's transaction could lead to the failure of the following `require` statement due to an insufficient balance of tokens: ```solidity=265 require( saleToken.balanceOf(address(vesting)) >= dcbAgreement.totalTokenOnSale, "Tokens not received from project" ); ``` Moreover, alterations to `dcbAgreement.totalTokenOnSale` and `dcbAgreement.hardcap` may disrupt the correlation between the deposited `value` and the calculated `numTokens`, which should ideally increase with the `value`. Such discrepancies can trigger a failure in `vesting.setCrowdfundingWhitelist(msg.sender, numTokens, value);`, as shown below, because the expected increase in `numTokens` and `value` may not occur after the modifications: ```solidity=328 uint256 numTokens = (value * dcbAgreement.totalTokenOnSale) / (dcbAgreement.hardcap); ``` If `numTokens` is less than the value before `dcbAgreement.totalTokenOnSale` and `dcbAgreement.hardcap` modification, then `vesting.setCrowdfundingWhitelist(msg.sender, numTokens, value);` will fail due to the following code snippet: ```solidity=321 function _setWhitelist(address _wallet, uint256 _amount, uint256 _value) internal { ... else { WhitelistInfo storage w = vestingPool.whitelistPool[whitelist.arrIdx]; totalVestedValue += _value - w.value; totalVestedToken += _amount - w.amount; ... ``` Other setter functions managed by privileged roles also pose similar risks. Incorrect configurations could prevent users from performing operations in this project or lead to loss of funds. Ensuring the integrity and reliability of these variables is crucial for maintaining the project's functionality and user trust.

In the `DCBTierMigrator` contract, the duplication check `require(eventToId[_event.dstAddress] == 0 || eventToId[_event.dstAddress] == _eventId, "Event already exists");` may not be sufficient enough within the `setEvent` function. It doesn't ensure that `_eventId` is within the `events` array's bounds, risking a runtime error if `_eventId` is out of range. Additionally, the function overwrites the event at `_eventId` without confirming an event already exists there, potentially leading to unintended data loss. Based on the project's logic, each event ID should be unique. However, the setting operation could lead to potential duplication and data overwrite.

The `registerForEvent` function allows users with a valid signature to register their allocation in two ways, without verifying the `hasRegistered[_eventId][msg.sender]` status. This enables users to register multiple times by repeatedly calling this function.

The linked functions calculate user information like deposits, multipliers, and tiers, depending heavily on third-party contracts, including: - `legacyStakingContract`, `legacyMultiAssetStakingContract`, `legacyCompounderContract`, `legacyLiquidityLocker`, `powerBoostContract`, `multiAssetStakingContract`, `compounderContract`, `liquidityLocker`, `_contract`, `compoundStakingContract`, `legacyMasterChef`, `_vault`. If the third-party contracts are compromised, it could affect the calculations of user data, potentially resulting in financial losses for the project.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f ```solidity=354 paymentToken.safeTransferFrom(_wallet, address(this), paymentAmount); ``` - Transferring tokens by `paymentAmount`. ```solidity=355 _setWhitelist(_wallet, _amount, _value); ``` - The `_value` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

In the `DCBPlatformVesting` contract, the `_doBuybackAndBurn` function uses the `swapExactTokensForTokens` function to exchange tokens based on the specified `amount`. However, this code snippet does not effectively guard against price slippage, especially in the context of a sandwich attack. During such an attack, an attacker spots a pending transaction that will impact the price of a token pair on a DEX like Uniswap. They then execute transactions both before and after the targeted transaction, aiming to manipulate the price for their benefit, thus causing significant slippage for the original transaction. ```solidity=357 uint256[] memory amountsOut = _router.getAmountsOut(amount, path); uint256 amountOut = (amountsOut[amountsOut.length - 1] * 99) / 100; //1% slippage ``` The code snippet calculates `amountOut` based on the current state of the pool (`_router.getAmountsOut(amount, path)`), and then sets a minimum acceptable amount out as 99% of this calculated value. However, if an attacker performs a transaction right before this transaction that significantly alters the pool's state (and hence the price), this transaction's `amountOut` calculation becomes outdated and ineffective in protecting against the new price impact. This function will not revert as `amountsOut[amountsOut.length - 1]` consistently reflects the actual amount received from the swap in this transaction, which is invariably higher than `amountOut`.

In the `DCBTierMigrator` contract, the `setMinShareForUser` function currently lacks validation for the `_minShareForUser` input parameter. Given that `minShareForUser` is used in the `registerForEvent` function to ensure participants meet a minimum share requirement, it's essential to validate `_minShareForUser` to be greater than zero. This validation would enhance code efficiency and ensure the `if` condition in `registerForEvent` serves its purpose effectively. ```solidity function registerForEvent(uint256 _eventId, bytes calldata _sig) external payable onlyValidSigner(_eventId, _sig) { ... if (_shares < minShareForUser) { (uint256 minLimit,,) = tiers.tierInfo(0); // First tier if (minLimit == 0) _shares = minShareForUser; } ... } ```

The `DCBTierMigrator` contract uses `ECDSAUpgradeable` from the OpenZeppelin library to identify the signer from provided signatures. Since the signatures (`_sig`) are directly submitted by the function callers, there's no guarantee they include the current chain ID. If the `_sig` and `eventHash` do not include the chain ID, this potentially exposes the system to cross-chain replay attacks, allowing the same signature to be used multiple times across different chains. ```solidity=49 address signer = ECDSAUpgradeable.recover(events[_eventId].eventHash, _sig); ```