Xpro

CertiKFiles named in the report

CertiK reviewed XPROJECT (Xpro) on 9 Jun 2023: 21 findings, 0 critical; 7 marked fixed, 3 acknowledged, 11 open.

No open critical findings
Open the reportOpen XPROJECT’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings21

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical000
High012
Medium022
Low1103
HighCentralization Risk Related to `addLiquidityETH`Fixed

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 ); ```

HighCentralization Risks in XProject.solFixed

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. ![](https://accelerator-tasks-prod.acc.corp.certik.com/fdb0075950014725b50c2f0dc5de3e98/diagrams/centralization_XProject-Ownable-_owner.svg) 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. ![](https://accelerator-tasks-prod.acc.corp.certik.com/fdb0075950014725b50c2f0dc5de3e98/diagrams/centralization_XProject-XPRO-_owner.svg)

MediumNo Upper Limit For FeesFixed

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.

MediumPotential Restore to Earlier FeeFixed

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; } ```

LowMissing Validation on `_maxTxAmount` and `maxTxPeFixed

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; ```

LowPotential `Out-of-Gas` IssueFixed

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

LowPotential Loose Validation on `removeAllFee` funcFixed

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

Contracts in scope

No deployed address is recorded for this audit.

The report names a repository or files. Open the report to see its scope.

Repository and files the report names (1)

  • XProject.sol

Part of XPROJECT’s security record

XPROJECT
Audits1 audit by 1 firmLast audit Jun 2023, by CertiK.
Critical findingsNo open critical findingsIn 1 report.
Open XPROJECT’s security record

Security firm

CertiK

1,044 projects reviewed · 1,375 reports · latest May 2025

See CertiK’s audits

Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.

Tell us