metaverse-user-dao---addendum II

### MetaUserDAOToken In the contract `Ownable` the role `_owner` has authority over the functions shown in the list and diagram below. * renounceOwnership() - Renounce the ownership of the contract. * transferOwnership() - Transfer the ownership of the contract to a new account. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and transfer or renounce the ownership of `MetaUserDAOToken` contract.  --- ### MudAngelRoundReleaseBank In the contract `MudAngelRoundReleaseBank` the role `admin` has authority over the functions shown in the list below. * depositMapping() - Map the deposits of investors from Ethereum mainnet to Polygon by transferring the amounts mapped in Ethereum to this contract in Polygon from `admin` account. * depositMappingFinalised() - Finish the deposits mapping. * getDepositInfo() - Get deposit information of users for mapping purpose. Any compromise to the `admin` account may allow the hacker to take advantage of this authority over the functions listed, which would allow them to potentially perform malicious actions. Specifically, the hacker could use the `depositMapping()` function to map the deposits of users who are not int the Ethereum mainnet. Furthermore, if the hacker completes the deposit mapping process using the `depositMappingFinalised()` function, it would become impossible for admin to map investors' deposits since the mapping process would be considered complete and irreversible. --- ### MudMiningEscrow In the contract `MudMiningEscrow` the role `admin` has authority over the functions shown in the list below. * depositMapping() - Map the deposits of users from Ethereum mainnet to Polygon by transferring the amounts mapped in Ethereum to this contract in Polygon from `admin` account. * getDepositOrderInfo() - Get order information of users for mapping purpose. Any compromise to the `admin` account may allow the hacker to take advantage of this authority over the functions listed, which would allow them to potentially perform malicious actions. Specifically, the hacker could use the `depositMapping()` function to map the deposits of users who are not int the Ethereum mainnet. --- ### MudABRoundReleaseBank In the contract `MudABRoundReleaseBank` the role `admin` has authority over the functions shown in the list below. * depositMapping() - Map the deposits of investors from Ethereum mainnet to Polygon by transferring the amounts mapped in Ethereum to this contract in Polygon from `admin` account. * depositMappingFinalised() - Finish the deposits mapping. * getDepositInfo() - Get deposit information of users for mapping purpose. Any compromise to the `admin` account may allow the hacker to take advantage of this authority over the functions listed, which would allow them to potentially perform malicious actions. Specifically, the hacker could use the `depositMapping()` function to map the deposits of users who are not int the Ethereum mainnet. Furthermore, if the hacker completes the deposit mapping process using the `depositMappingFinalised()` function, it would become impossible for admin to map investors' deposits since the mapping process would be considered complete and irreversible. --- ### MudTeamReleaseBank In the contract `MudTeamReleaseBank` the role `admin` has authority over the functions shown in the list below. * teamMemberDeposit() - Distribute `MUD` tokens to team members and lock the tokens in the contract during ICO phrase. * icoFinalised() - Finish ICO phrase. Any compromise to the `admin` account may allow the hacker to take advantage of this authority over the functions listed, which would allow them to potentially perform malicious actions. Specifically, the hacker could use the `teamMemberDeposit()` function to distribute `MUD` tokens to team members and lock the tokens in the contract during the ICO phase. However, if the hacker could distribute the tokens to themselves or their own account instead of the actual team members, resulting in the theft of tokens. Additionally, the hacker could use the `icoFinalised()` function to prematurely finish the ICO phase, which would prevent admin from depositing `MUD` tokens to team members and potentially lead to a loss of confidence in the project. --- ### MudMiningPool In the contract `MudMiningPool` the role `admin` has authority over the functions shown in the list below. * poolInfoMappingDeposit() - Migrate the `MUD` balance of pool contract from Ethereum mainnet to Polygon by transferring the amounts mapped in Ethereum to this contract in Polygon from `admin` account. * poolInfoMapping() - Map the mined data from Ethereum mainnet to Polygon once the `MUD` token in Ethereum was frozen. * poolInfoMappingFinalized() - Set the migrating status finished. * getPoolInfo() - Get pool information

All of the `MUD` tokens will be sent to the contract deployer during deployment in `Polygon`. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

In the contract `MetaUserDAOToken`, the role `creator` has the authority to update the value of `_frozen` to true, which will irreversibly suspend all transfer functions of the token. ```solidity= function mainNetMappingFreeze() external { require(msg.sender == creator, "Not token creator!"); require(!_frozen, "Freezed for mainnet mapping !"); _frozen = true; } ``` Any compromise to the private key of the `creator` may allow hackers to take advantage of this authority and prevent token transfer functions.

Upon completion of the mapping process from Ethereum to Polygon, the `MUD` token in Ethereum will be frozen, preventing users who hold `MUD` tokens in Ethereum from transferring or staking them. If there is any plan or process in place to compensate users for their `MUD` balance in Ethereum. Besides, the total number of `MUD` token deployed in Polygon will be `978118023075739`, what does this number come from? Does it mean the total supply number of `MUD` token mapped in Ethereum at a certain block?

There are some hardcoded values in the codebase, especially those that may be used for testing purposes, for example, the `mudtTokenContractAddr` address. ```solidity library UtilityFunctions { address constant mudtTokenContractAddr = address(0x90a34C6ce471382c8d0296E84264d0aA85aac68a);//contrct address of the MUD token, should deploy the token contract first and set the contract address here function getMudToken() internal pure returns(MetaUserDAOToken){ MetaUserDAOToken token = MetaUserDAOToken(mudtTokenContractAddr); return token; } } ``` It is important to remind the client to review and check these hardcoded values carefully before deploying the contract to the Polygon mainnet. The concern with hardcoded values is that they are static and cannot be easily changed once the contracts are deployed. If these values are not properly reviewed and updated, they can lead to unintended behavior or security vulnerabilities in the deployed contract. Hardcoded values may include addresses, keys, or other configuration parameters that affect the contract's functionality.

The codebase contains multiple Solidity versions, which can lead to unexpected behavior, potential vulnerabilities, difficulties in maintaining the code, and inconsistencies in the execution of the smart contract. Using different versions may also result in increased complexity during code auditing, as different security features and bug fixes are present in different versions of the compiler. Versions used: `0.8.9`, `^0.8.0` `0.8.9` is used in polygonTeamRelease.sol file. ```solidity=2 pragma solidity 0.8.9; ``` `^0.8.0` is used in Token_flattened.sol file. ```solidity=736 pragma solidity ^0.8.0; ```

There is a potential issue in the functions listed which utilize a loop to iterate over arrays, and could potentially result in a high amount of gas consumption. If the array contains an exceedingly large number of elements, the loop may consume more gas than is available in a single block. This would cause the transaction to fail with the "out of gas" error.