XPROJECT security record

In `addLiquidity()` function, `uniswapV2Router.addLiquidityETH{value: ethAmount}` will be called with the `to` argument set to the address `owner()` for acquiring the generated LP tokens from the corresponding pool. As a result, over time, the address `owner()` address will accumulate a significant portion of LP tokens. Mishandling its private key can have devastating consequences to the project as a whole. ```solidity=706 uniswapV2Router.addLiquidityETH{value: ethAmount}( address(this), tokenAmount, 0, 0, owner(), block.timestamp ); ```

In the contract `Ownable` 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.  In the contract `XPRO`, beyond functions mentioned in `Ownable`, 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. 

It is possible to set these fees, including `_taxFee`, `_developmentFee` and `_liquidityFee` to any value as there are no upper limits on the percentage of these fees.

The remove fee will be skipped when `_taxFee` or `_liquidityFee` are 0: ```solidity=628 function removeAllFee() private { if(_taxFee == 0 && _liquidityFee == 0) return; _previousTaxFee = _taxFee; _previousDevelopmentFee = _developmentFee; _previousLiquidityFee = _liquidityFee; _taxFee = 0; _developmentFee = 0; _liquidityFee = 0; } ``` This means the previous fee will not be updated during the process. The concern arises when, in such a scenario, the fee for the contract is restored to its previous value. This is because the `restoreAllFee` function does not include any corresponding skip logic: ```solidity=637 function restoreAllFee() private { _taxFee = _previousTaxFee; _developmentFee = _previousDevelopmentFee; _liquidityFee = _previousLiquidityFee; } ```

In contract `XProject`, the owner of the contract may update the `_maxTxAmount` via `setMaxTxPercent` function. However, there is no limitation on `maxTxPercent`, as well as, `_maxTxAmount`. This may cause issues, for example, 1. `_maxTxAmount` may be large than `_tTotal` when `maxTxPercent` is larger than 1000 2. `_maxTxAmount` may be less than `numTokensSellToAddToLiquidity`, the `swapAndLiquify` function will never be triggered. ```solidity=666 bool overMinTokenBalance = contractTokenBalance >= numTokensSellToAddToLiquidity; ```

The `Out-of-Gas` issue with the function `includeInReward()` is that it uses a loop to iterate over `_excluded`, which could potentially result in a high amount of gas consumption. If `_excluded` contains a 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. ```solidity=514 for (uint256 i = 0; i < _excluded.length; i++) { if (_excluded[i] == account) { _excluded[i] = _excluded[_excluded.length - 1]; _tOwned[account] = 0; _isExcluded[account] = false; _excluded.pop(); break; } } ``` Besides, function `_getCurrentSupply()` may have the same issue as it also utilizes the same loop over `_excluded`.

The `removeAllFee` function will be invoked when from or to address is excluded from fee during the transfer. ```solidity=715 function _tokenTransfer(address sender, address recipient, uint256 amount,bool takeFee) private { if(!takeFee) removeAllFee(); ... } ``` The remove fee will be skipped when `_taxFee` or `_liquidityFee` are 0: ```solidity=628 function removeAllFee() private { if(_taxFee == 0 && _liquidityFee == 0) return; _previousTaxFee = _taxFee; _previousDevelopmentFee = _developmentFee; _previousLiquidityFee = _liquidityFee; _taxFee = 0; _developmentFee = 0; _liquidityFee = 0; } ``` The issue at hand is that the owner has the ability to modify all fees to any arbitrary value, provided that `_taxFee` and `_liquidityFee` are set to 0, while `_developmentFee` remains non-zero. In such a scenario, all users will incur charges corresponding to the `_developmentFee`.