Seedify security record

**Note:** The finding only concerns those centralized functions within the scope of the audit, and does not include those which may exist within the contract due to out-of-scope inheritances. ### LzIDO.sol In the contract `LzIDO`, the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and update the refund period both in the `LzIDO` contract and in the corresponding cross-chain `LzLinearVesting` contract.  In the contract `LzIDO`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the destination chain id from its original, changing the chain the contract sends messages to and receives messages from.  --- ### LzLinearVesting.sol In the contract `LzLinearVesting`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the destination chain id from its original, changing the chain the contract sends messages to and receives messages from. 

In the contract `INO`, the role `admin` has the authority to update the implementation contract behind the contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract appointed by proxy and therefore execute potential malicious functionality in the implementation contract.

In the contract `LinearVesting` the role `_owner` has authority over the functions shown below. - `pause()`: Pauses all vesting activities, preventing users from claiming tokens. Only the contract owner (`onlyOwner`) can call this function. - `unpause()`: Unpauses all vesting activities, allowing users to resume claiming tokens. Only the contract owner (`onlyOwner`) can call this function. - `update(bytes32 merkleRoot_, uint32 startTime_, uint32 endTime_, uint256 toClaim)`: Updates the vesting schedule settings, including the Merkle root, start time, end time, and the amount of tokens to be claimed. It also allows the transfer of additional tokens to the contract for vesting. Only the contract owner (`onlyOwner`) can call this function. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functionalities of the project.

In the contract `SMD_v5` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set rewards periods, extend the current period, pause/unpause functions, and withdraw excess tokens mistakenly sent to the contract. Notably, the hacker can prevent users from withdrawing staked tokens by updating `lockDuration` to a large value via `setNewPeriod()`. 

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrive in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. If `tokenAddress` (the staking token) is deflationary, an attacker can repeatedly call `deposit()` and `withdraw()`/`emergencyWithdraw()` to empty the contract's funds and put other users' tokens at risk. Similarly, if the `rewardTokenAddress` (the rewards token) is deflationary, the actual balance is lower than anticipated, leaving the potential for insufficient funds when disbursing rewards. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

In the contract `BlackBoxVanguard` from the commit hash `58381fbee616cd801f73dde2d25dc6e8eacf11a6`, the role `_owner` has authority over the functions shown in the diagram below.  In addition, the `openBox()` function is callable when it is both the box owner and the `_owner` address. The `findBox()` is callable by the whitelisted addresses that can be verified by MerkleProof library, which are not defined in the scope of this contract. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. --- In the contract `Vanguard` from the commit hash `58381fbee616cd801f73dde2d25dc6e8eacf11a6`, the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority.  In the contract `Vanguard` from the commit hash `58381fbee616cd801f73dde2d25dc6e8eacf11a6`, the role `boxContractAddress` has authority over the functions shown in the diagram below. Any compromise to the `boxContractAddress` account may allow the hacker to take advantage of this authority.  --- Note that this finding is also applicable in the `dc1b4d74d3968e855911145c54adce7b6d82b040` commit. Please see the alleviation section for the functions changing details.

In the contract `SeedifyFundBUSD.sol` the role `_owner` has authority over the functions: - `addWhitelist()` - `updateTierUsersValue()` - `updateTierValues()` - `setTokensPerBUSD()` - `setRefundThresholdTime()` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and 1) Add users to the whitelist using the `addWhitelist()` function allowing them to buy tokens using the `buyToken()` function. 2) Change the `tiersMaxCap[]` array that decides the maximum amount of tokens that can be bought by users of one particular tier, and the `maxAllocaPerUserInTiers[]` array that decides the amount of tokens that can be bought by a user in a particular tier. 3) Change the 'totalUserInTiers[]' array that keeps track of the total number of users in a whitelist, alongside the `maxAllocaPerUserInTiers[]` array. 4) Change the `tokensPerBUSD` and `refundThresholdTime` using the `setTokensPerBUSD()` and `setRefundThresholdTime()` functions respectively. In addition, in the contract `SeedifyFundBUSD.sol` the `projectOwner` is set in the `constructor()` and receives all `BUSD` from buys and also is the source of `BUSD` in `refund()`. If the `projectOwner` does not hold enough `BUSD`, then `refund()` will revert. In the contract `INOLaunchpadSmartContract.sol` the role `_owner` has the authority over the following functions: - `updateNFTprice()` - `pause()` - `unpause()` - `addWhitelist()` - `removeWhitelist()` Any compromise to the '_owner' account may allow the hacker to take advantage of this authority and 1) Alter the `nftPrice` using the `updateNFTprice()` function. 2) Prevent everyone from buying new tokens using the 'pause()' function. 3) Allow users to buy new tokens using the `unpause()` functions, when they are not intended to. 4) Add or remove users from the `whitelist[]` array, using the `addWhitelist()` and `removeWhitelist()` functions respectively.

The report gives no description here.

The report gives no description here.

In the `update()` function of the `LinearVesting` contract, there is a lack of validation for the `startTime_` parameter. Specifically, the function does not check whether `startTime_` is greater than the current block timestamp (`block.timestamp`). This omission allows for the possibility of setting a start time in the past, which could lead to unexpected behavior in the vesting logic and potentially enable exploitation by malicious actors. Similarly, updating `endTime_` without considering the current claimed tokens may bring unexpected result.