Metaverse User DAO security record

In the contract `MUDUniswapV3Staker` the role `admin` has authority over the functions shown in the list and diagram below. * unstakeForMainnetMapping() - This function unstakes all liquidity NFT positions associated with a specified address, regardless of the contract's expiry time. * getContractCount() - The admin role can use this function to retrieve the total number of staking contracts associated with a specific address. * getContractInfo() - With this function, the admin role can obtain information about a particular staking contract. * getContractInfoByTokenId() - The admin role has the authority to retrieve information about a specific staking contract using the tokenId (liquidity NFT position ID). Any compromise to the `admin` account may allow the hacker to take advantage of this authority. They could potentially query the staking information of any account, which should be considered sensitive and only accessible to the staking owner. Furthermore, the hacker could also unstake the liquidity NFTs associated with any account. 

### 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.

In the contract `MudAngelRoundReleaseBank` the role `admin` has authority over the functions shown below: * icoDeposits(): deposit `MUD` tokens to investor. * icoFinalised(): mark the `ICO` finished flag, stop `icoDeposit`. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and do the following: * Deposit `MUD` tokens to themselves or block `ICO`. In the contract `MudTeamReleaseBank` the role `admin` has authority over the functions shown below: * teamMemberDeposit(): deposit `MUD` tokens to team members, lock the team's `MUD` tokens to the contract and start to release after 365 days in daily release rate. * icoFinalised(): mark the `ICO` finished flag, stop `icoDeposit`. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and do the following: * Deposit `MUD` tokens to themselves or block `ICO`. In the contract `MudMiningPool` the role `admin` has authority over the functions shown below: * icoDeposit(): deposit `MUD` tokens to the pool. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and do the following: * Refuse deposit `MUD` tokens. In the contract `MudMiningPool` the role `miningDappAddress` has authority over the functions shown below: * miningStart(): start mining process. * miningSettlement(): settle mining tokens. Any compromise to the `miningDappAddress` may allow the hacker to take advantage of this authority and do the following: * Start mining process at any time as they want. * Settle tokens to themselves.

The team introduced a slippage mechanism in the commit [35ee42f3d5f86ca6abe4e66dcc80b00e7e71da93](https://github.com/MetaUserDAO/MUDUniswapV3Staker/tree/35ee42f3d5f86ca6abe4e66dcc80b00e7e71da93). This mechanism incorporates the `slippageFactor` parameter to ensure that the minimum liquidity tokens added surpass set thresholds, dictated by `usdtToStake` and `mudToStake`. ```solidity function createNewStakingContract(uint256 usdtToStake, uint256 mudToStake, uint8 duration, uint nodeId, uint256 slippageFactor) external returns ( uint256 tokenId, uint128 liquidity, uint256 amount0, uint256 amount1, uint startTime, uint endTime ) ``` The slippage threshold is derived as follows: ```solidity INonfungiblePositionManager.MintParams memory params = INonfungiblePositionManager.MintParams({ token0: usdtAddr, token1: mudAddr, fee: 3000, tickLower: -887220, //this will be adapted to reflect the actual MUD/USDT token pair on the polygon mainnet tickUpper: 887220, //this will be adapted to reflect the actual MUD/USDT token pair on the polygon mainnet amount0Desired: amount0ToMint, amount1Desired: amount1ToMint, amount0Min: SafeMath.mul(amount0ToMint, slippageFactor) / 1000, // slippage safeguard amount1Min: SafeMath.mul(amount1ToMint, slippageFactor) / 1000, // slippage safeguard recipient: address(this), deadline: block.timestamp }); ``` In the `createNewStakingContract()` function, the slippage factor used for calculating the minimum amounts (`amount0Min` and `amount1Min`) required for the liquidity minting is based on the user-provided token amounts (`amount0ToMint` and `amount1ToMint`), rather than the actual amounts needed for the liquidity. This approach can lead to transaction reverts if users stake a large number of `MUD` or `USDT` tokens without knowing the actual proportion between the two tokens. The slippage factor is applied to the user-provided amounts, which may result in unrealistically high minimum amounts. If the actual amounts needed for the liquidity are lower than the slippage-adjusted amounts, the transaction will fail. Additionally, the fix requires users carefully set the `usdtToStake`, `mudToStake` and `slippageFactor`. If those parameters are not properly set, it could still lead to a possible sandwich attack. For example, if the amount of `usdtToStake` and `mudToStake` deviate from the current ratio of usdt:mud in the pool, the threshold that is based on `usdtToStake` and `mudToStake` may be unable to protect from slippage and thus cause the potential loss due to slippage (as the above test case demonstrate).

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?

In the function `miningSettlement()` of contract `MudMiningPool`, the `dailyMiningLimit` is just checked whether it should be halved only in the last settlement batch. If current settlement is divided into 5 batches (1,2,3,4,0), and it has been 4 years since the last `lastHalvingTime`, according to the logic, only in the last batch (batchNumber = 0) the `dailyMiningLimit` will be halved. In this case, it should be halved starting from batch #1. Besides, the half time could happen in any batch during a settlement.

In the function `createNewStakingContract()`, it passes the fixed values of `tickLower` and `tickUpper` while adding liquidity for a specific trading pair. There doesn't appear to be any immediate issue with the code snippet itself. However, it's important to note that these fixed values may not be suitable for all scenarios. The `tickLower` and `tickUpper` values may need to be adjusted based on the actual MUD/USDT token pair on the Polygon mainnet. It's crucial to ensure that the `tickLower` and `tickUpper` values align with the price range of the actual trading pair. Selecting inappropriate ranges for `tickLower` and `tickUpper` could result in insufficient liquidity provision or an inability to meet the trading demands. ```solidity=174 INonfungiblePositionManager.MintParams memory params = INonfungiblePositionManager.MintParams({ token0: usdtAddr, token1: mudAddr, fee: 3000, tickLower: -887220,//this will be modified to the actual token pair MUD/USDT of polygon mainnet tickUpper: 887220,//this will be modified to the actual token pair MUD/USDT of polygon mainnet amount0Desired: amount0ToMint, amount1Desired: amount1ToMint, amount0Min: 0, amount1Min: 0, recipient: address(this), deadline: block.timestamp }); // Note that the pool defined by MUD/USDT and fee tier 0.3% must already be created and initialized in order to mint (tokenId, liquidity, amount0, amount1) = nonfungiblePositionManager.mint(params); ```

The contract serves as the interface for interacting with the third-party protocol `Uniswap V3`, which involves the utilization of specific addresses associated with the protocol. These addresses include: - `IUniswapV3Pool`: Address related to the `Uniswap V3` pool. - `INonfungiblePositionManager`: Address associated with the non-fungible position manager of `Uniswap V3`. - `IUniswapV3Factory`: Address of the `Uniswap V3` factory. During the audit process, the third-party entities are treated as black boxes, assuming their functional correctness. However, it's important to acknowledge that in real-world scenarios, third-party entities can be compromised, potentially resulting in the loss or theft of assets. In addition to the third-party addresses, there are also addresses involved in the contract's business logic: - `daoFundAddress`: The address of the MUD DAO fund, which receives confiscated USDT. Currently, it is implemented as a Gnosis proxy address. - `usdtAddr`: The address of the USDT token. Currently, it is set as a testing token address. - `mudAddr`: The address of the MUD token deployed on the blockchain. Currently, it is set as a testing token address. It is assumed that these addresses are valid and secure actors, and appropriate logic has been implemented to facilitate collaboration with the current project.