Metacraft.

In the `withdrawAllFunds()` function, there's a critical flaw where the total invested amount (`investedAmount[tokenAddress_]`) is reduced by the current balance of the token within the contract (`IERC20(tokenAddress_).balanceOf(address(this))`). This operation assumes that the contract's token balance only increases through legitimate investment actions via `investInWithVerify()`. However, an attacker could artificially increase the contract's token balance by directly transferring tokens to it. If such an action occurs, the subtraction operation could lead to an underflow in `investedAmount[tokenAddress_]`, potentially causing legitimate invested tokens to become permanently locked in the contract due to an inaccurate representation of available funds. ```solidity=702 function withdrawAllFunds(address tokenAddress_) external nonReentrant notContract(msg.sender) withdrawAddressOnly() { uint256 balance = IERC20(tokenAddress_).balanceOf(address(this)); require(investCoinAddress == tokenAddress_ || projectCoinAddress == tokenAddress_, "Coin Address Not Correct!"); require(block.timestamp - claimTimestamp >= 3 days, "Withdraw Fund Until 48 hours after Claim "); if(tokenAddress_ == investCoinAddress){ investedAmount[tokenAddress_] -= balance; refundedAmount[tokenAddress_] += balance; emit IDOStatusChange(tokenAddress_, balance, msg.sender, "Manager Withdraw invest Coins"); } else if(tokenAddress_ == projectCoinAddress){ projectCoinAmount[tokenAddress_] = IERC20(tokenAddress_).balanceOf(address(this)); claimedAmount[tokenAddress_] += balance; emit IDOStatusChange(tokenAddress_, balance, msg.sender, "Manager Withdraw invest Coins"); } else revert("withDraw TokenAddress ERROR"); IERC20(tokenAddress_).safeTransfer(msg.sender, balance); } ```

The function `removeOwner()` can be called by anyone as it has no access restriction. This enables anyone to call this and remove any multisig `_owners`.

The `deleteMaxPendingTx()` function within the contract utilizes a time lock mechanism, `maxPendingTime`, intended to restrict the deletion of pending proposals until a certain period has passed. However, a valid owner can bypass this time lock by directly invoking `deleteTransaction()` to delete pending proposals.

In the `withdrawAllFunds()` function, there's an inconsistency between the implemented logic and the comment. The code enforces a condition that restricts fund withdrawal until 72 hours (3 days) have passed since the `claimTimestamp`. However, the comment misleadingly states a 48-hour (2 days) wait period. ```solidity=709 require(block.timestamp - claimTimestamp >= 3 days, "Withdraw Fund Until 48 hours after Claim "); ```

The `investInWithVerify()` function is designed to accept `userLevel` values of only 1, 2, and 3, aligning with specified access or participation levels. Despite this restriction, there are instances within the contract where `userLevel` 4 is used.

The following comment is outdated and incorrect since the contract logic has been changed. ```solidity=393 require(block.timestamp - transaction.timestamp >= 24 hours,"Time Lockin for 48 Hours for at Least 2 signers !"); ```

The `deleteMaxPendingTx()` function within the contract utilizes a time lock mechanism, `maxPendingTime`, intended to restrict the deletion of pending proposals until a certain period has passed. Currently, this time lock is set to 96 seconds, a duration significantly shorter than the intended design of 96 hours. This discrepancy could lead to premature deletion of pending proposals, potentially undermining the governance process or other sequential actions reliant on the time lock mechanism.

In the `withdrawAllFunds()` function, when the `tokenAddress_` parameter matches the `projectCoinAddress`, the `projectCoinAmount[projectCoinAddress]` captures the token balance before the token transfer, contrary to the intended behavior of recording the current token balance.

The implementation of the `notContract` check can not cover all scenarios. The check can be bypassed if the call is from the constructor of a smart contract or when the contract is destroyed. In that case, the codesize will also be zero. ```solidity modifier notContract(address _address) { uint256 codeSize; assembly { codeSize := extcodesize(_address) } require(codeSize == 0, "Contracts are not allowed to receive tokens"); _; } ```

`ecrecover()` accepts as valid, two versions of signatures, meaning an attacker can use the same signature twice, or an attacker may be able to front-run the original signer with the altered version of the signature, causing the signer's transaction to revert due to nonce reuse.