Metacraft.

In the contract `MetaCraftIDO` 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 the project coin and initiate proposals to update `withdrawAddress` and add/remove a multisig wallet.  In the contract `MetaCraftIDO` the role `withdrawAddress` has authority over the functions shown in the diagram below. Any compromise to the `withdrawAddress` account may allow the hacker to take advantage of this authority and transfer tokens out of the contract 72 hours after the claim timestamp.  In the contract `MetaCraftIDO` the role `publicKey` can provide signatures for the following functions: - `setProjectInfo()` - `investInWithVerify()` - `refundOut()` - `depositProjectCoin()` - `claimProjectCoin()` Any compromise to the `publicKey` account may allow the hacker to take advantage of this authority and allow unauthorized users to modify critical variables, invest, refund, deposit, and claim. In the contract `MetaCraftIDO` the role `_owners` has authority over the following functions: - `setProjectInfo()` - `signUserAdd()` - `signUserDel()` - `signTransaction()` - `executeTransaction()` Any compromise to the `_owners` accounts (multisig wallets) may allow the hacker to take advantage of this authority and modify critical variables; delete a proposal or approve a proposal to update the `withdrawAddress`, add/remove addresses from `_owners`. It's important to note that a proposal requires approvals from 3 `_owners`.

The project design may not be compatible with non-standard ERC20 tokens, such as deflationary tokens or rebase tokens. The functions use `transferFrom()` to move funds from the sender to the recipient but fail to verify if the received token amount matches the transferred amount. This could pose an issue with fee-on-transfer tokens, where the post-transfer balance might be less than anticipated, leading to balance inconsistencies. There might be subsequent checks for a second transfer, but an attacker might exploit leftover funds (such as those accidentally sent by another user) to gain unjustified credit.

The `withdrawAllFunds()` function in the contract allows the withdrawal of project coins under the condition that all users have withdrawn their allocated tokens. This mechanism creates a potential deadlock where the withdrawal of project coins by the managing entity can be indefinitely blocked if even a single user fails to withdraw their tokens. This design inadvertently grants any user the power to prevent the withdrawal of project coins, posing a significant risk to lock the project tokens in the contract. ```solidity function withdrawAllFunds(address tokenAddress_, uint256 amount_) external nonReentrant notContract withdrawAddressOnly() { uint256 balance = IERC20(tokenAddress_).balanceOf(address(this)); require(balance >= amount_, "balance insufficent!"); require(investCoinAddress == tokenAddress_ || projectCoinAddress == tokenAddress_, "Coin Address Not Correct!"); require(block.timestamp - claimTimestamp >= 3 days, "Withdraw Fund Until 72 hours after Claim "); uint256 investAmount = investedAmount[investCoinAddress]; uint256 claimAmount = claimedAmount[projectCoinAddress]; if(tokenAddress_ == investCoinAddress){ refundedAmount[tokenAddress_] += amount_; emit IDOStatusChange(tokenAddress_, amount_, msg.sender, "Manager Withdraw invest Coins"); } else if(tokenAddress_ == projectCoinAddress){ require((investAmount * 10 ** decimals / projectCoinPrice - claimAmount == 0 ),"Some others not claimed, can not withdraw so many!"); projectCoinAmount[tokenAddress_] -= amount_; claimedAmount[tokenAddress_] += amount_; emit IDOStatusChange(tokenAddress_, amount_, msg.sender, "Manager Withdraw invest Coins"); } else revert("withDraw TokenAddress ERROR"); IERC20(tokenAddress_).safeTransfer(msg.sender, amount_); } ```

The functions `signUserAdd()` and `signUserDel()` lack the implementation of a time lock mechanism, unlike the `signTransaction()` function.

The contract sets the following default timestamps that are earlier than the current date (April 3, 2024), affecting the ability to perform deposit operations and other time-sensitive functions. ```solidity=27 uint256 public startTimestamp = 1711035000; uint256 public endSellTimestamp = 1711040000; uint256 public protectTimestamp = 1711045000; uint256 public claimTimestamp = 1711050000; ```

The following functions need the `publicKey`'s signature to be invoked: - setProjectInfo() - investInWithVerify() - refundOut() - depositProjectCoin() - claimProjectCoin() However, in the current design, these functions do not include validations to prevent the reuse of signatures across multiple transactions. Moreover, the signature mechanism lacks specificity, as the signature does not include token amounts for operations including `setProjectInfo()`, `depositProjectCoin()`, and `investInWithVerify()`. This could potentially lead to security vulnerabilities, such as signature replay attacks or unauthorized actions not explicitly approved by the signer. Additionally, the signature includes `userLevel`. If a user's `userLevel` has been changed, they can still use the previous `userLevel` to invest.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=23 address public projectCoinAddress;//raisecoinaddress ``` - The functions `depositProjectCoin()` and `claimProjectCoin()` interact with third party contract with `IERC20` interface via `projectCoinAddress`. --- ```solidity=24 address public investCoinAddress; //moneyaddress ``` - The functions `refundOut()` and `investInWithVerify()` interact with third party contract with `IERC20` interface via `investCoinAddress`.