Unchain-X

The Centralization Related Risks included in this finding are only related to those in the scope of the audit. Some of the in scope contracts inherit contracts that were not included in the scope, which have privileged roles. These privileged roles were not considered in this finding or audit as they are considered out of scope. We highly recommend users and the client to carefully review privileges given throughout the entire codebase. --- ### UNXwapV3Factory In the contract `UNXwapV3Factory` 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 do the following: - Change the `owner` to an address they control or remove the `owner` access from all accounts to prevent needed updates. - Enable a new fee amount less than 100 percent with any tickspacing that is greater than zero, but less than 16384. - Create a pool for any pair of tokens, including malicious tokens, without paying a deployment fee.  --- ### UNXwapV3Manager In the contract `UNXwapV3Manager` the roles `owner` or `executor` has authority over the functions shown in the diagram below. Any compromise to the `owner` or `executor` accounts may allow the hacker to take advantage of this authority and do the following: - Change the protocol fee for pools. It can be set to zero, or $\frac1N$ of the fee amount, where $N$ is between 4 and 10. - Change the deployment fee of a v3 pool contract to any value. - Enable a new fee amount less than 100 percent with any tickspacing that is greater than zero, but less than 16384. - Enable user to be able to create new Pools and be subjected to the deployment fee if it is set. - Change the deploy fee token to any token. - Change the deploy fee collector to an address they control, in order to steal the deployment fee for themselves. - Change the `lmPool` contract address so that there is an inconsistency between the `v3Pool` and its associated `lmPool` or to cause a denial of service. - List, delist, or allocate rewards via calls to the `lmFactory` contract. (See Centralization Risks in `lmFactory`) - Collect protocol fees from the `v3Pools` for themselves.  In addition, the roles `owner` or `executor` have authority over the function `setMaxAllocation()`. Any compromise to the `owner` or `executor` accounts may allow the hacker to take advantage of this authority and set the max allocation in the `UNXwapV3LmFactory` to a smaller or larger value to under-allocate or over-allocate rewards. --- In the contract `UNXwapV3Manager` the role `owner` has authority over the functions: - `setFactoryOwner()` - `setLmFactory()` - `setNfpManager()` Any compromise to the `owner` account may allow the hacker to take advantage of this authority and do the following: - Change the factory contract owner to an address they control. - Set the `lmFactory` contract address to a malicious contract that will make malicious calls during sensitive state changes of a v3 pool contract. - Change the `nfpManager` contract to a malicious contract, allowing them to take advantage of the authority.  --- In the contract `UNXwapV3Manager` the role `nfpManager` has authority over the functions listed below. - `createPool()` Any compromise to the `nfpManager` account may allow the hacker to take advantage of this authority and create a pool with a bad pair of tokens. --- ### UNXwapV3Pool In the contract `UNXwapV3Pool` the owner of the `UNXwapV3Factory` has authority over the functions shown in the diagram below. Any compromise to the owner of the `UNXwapV3Factory` may allow the hacker to take advantage of this authority and do the following: - Change the `lmPool` contract address so that there is an inconsistency between the `v3Pool` and its associated `lmPool` or to cause a denial of service. - Change the protocol fee for pools. It can be set to zero, or $\frac1N$ of the fee amount, where $N$ is between 4 and 10. - Collect protocol fees from the pool for themselves.  --- ### HalvingProtocol In the contract `HalvingProtocol` 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 themselves as an operator to execute the privileged actions outli

All of the `UNXToken` tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs 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. The contract at address [https://bscscan.com/address/0x4F0572cA0BF96F5ae17B7062D97ceA3f35BDeA6f#code](https://bscscan.com/address/0x4F0572cA0BF96F5ae17B7062D97ceA3f35BDeA6f#code) has the following distribution information: - The `totalSupply` of the token is 10000000000000000000000000000 (10,000,000,000 tokens). - The distribution of funds is as follows (as seen at [https://bscscan.com/token/0x4F0572cA0BF96F5ae17B7062D97ceA3f35BDeA6f#balances](https://bscscan.com/token/0x4F0572cA0BF96F5ae17B7062D97ceA3f35BDeA6f#balances)) - Address 0xBA2D44ebf3A6A2543c7825e94f673bdE0960EcC6 (GenesisX Contract) holds 9,550,000,000 of the tokens (95.5%) - Address 0x64A7e3e489D6709B549f27009a4dCceb0DB50188 (Launchpad Factory Contract) holds 331,515,000 of the tokens (3.3152%) - Address 0x6a924a143476753395BdE8a0565baCccDF90Abcf (Externally Owned Account) holds 118,485,000 of the tokens (1.1849%)

Throughout the codebase, the input used within the cited functions is lacking proper validation checks to ensure it works as intended.