Quantum Audit Logo

Is XPULS Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

XPULS XPULS
0xabae…8228
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The XPLUSToken contract implements a custom ERC20 token with complex tax mechanisms for buy and sell transactions, integrating with Uniswap V2. The audit identified several medium and low-severity issues related to the custom tax logic, dynamic trading caps, and non-standard Uniswap math. A significant portion of the `_transfer` function and related logic was truncated in the provided source code, limiting the depth of the analysis and potentially concealing further vulnerabilities. The contract utilizes OpenZeppelin libraries for security and access control, but its custom logic introduces complexity and potential risks.

1 High3 Medium2 Low1 Informational
Volume 24h
$0.0700
Liquidity
$20.0600
Price
$0.00004457
Token Age
6mo
Top 10 Holders
37.9%

Security Findings

1 High3 Med2 Low1 Info
High

Centralization Risk via Owner Privileges and Immutable Setup

H-01The `owner` (deployer) has significant control over the token's initial operational phase. The `setPresale()` function, callable only by the owner, initiates the token's trading by calling `launch()` and `updatePoolReserve()`. This single point of control for enabling trading, combined with the immutable setting of critical fee distribution addresses (marketing, node, protection fund) during deployment, means a compromise of the owner's key could severely impact the project's launch and initial fund distribution. While `Ownable` is a standard pattern, the impact of this centralization at launch is high.
IssueThe `owner` (deployer) has significant control over the token's initial operational phase. The `setPresale()` function, callable only by the owner, initiates the token's trading by calling `launch()` and `updatePoolReserve()`. This single point of control for enabling trading, combined with the immutable setting of critical fee distribution addresses (marketing, node, protection fund) during deployment, means a compromise of the owner's key could severely impact the project's launch and initial fund distribution. While `Ownable` is a standard pattern, the impact of this centralization at launch is high.
FixImplement a multi-signature wallet for the `owner` address to mitigate the risk of a single point of failure. Consider a time-locked or governance-controlled mechanism for critical launch parameters if applicable, rather than sole owner discretion. Ensure all critical addresses are thoroughly vetted before deployment, as they are immutable.
StatusUnresolved
Medium

High and Complex Tax Mechanism with Incomplete Logic

M-01The contract implements high buy (3.5%) and sell (3.5%) tax rates with intricate, multi-step distribution logic within the `_transfer` function. This complexity increases the attack surface and the likelihood of calculation errors or unexpected behavior. Furthermore, the `totalProfitTaxRate` variable is declared but its application is not visible in the provided `_transfer` function, suggesting incomplete or missing critical economic logic. The `_swapAndDistribute` function, which is likely central to fee handling, is also truncated.
IssueThe contract implements high buy (3.5%) and sell (3.5%) tax rates with intricate, multi-step distribution logic within the `_transfer` function. This complexity increases the attack surface and the likelihood of calculation errors or unexpected behavior. Furthermore, the `totalProfitTaxRate` variable is declared but its application is not visible in the provided `_transfer` function, suggesting incomplete or missing critical economic logic. The `_swapAndDistribute` function, which is likely central to fee handling, is also truncated.
FixSimplify the tax calculation and distribution logic where possible to improve readability and reduce the risk of errors. Ensure all declared tax rates, especially `totalProfitTaxRate`, are fully implemented and their effects are clearly understood. Provide the complete source code, including `_swapAndDistribute`, for a thorough review of the entire tax mechanism.
StatusUnresolved
Medium

Dynamic 'Max Cap Buy/Sell' Based on Current Reserves

M-02The `_transfer` function imposes dynamic limits on buy and sell transactions, restricting them to `amount <= reserveThis / 10` (10% of the token's reserve in the Uniswap pair). This dynamic cap, while potentially intended to prevent large price impacts, makes trading highly dependent on current liquidity. If reserves are low, users might be unable to execute even small trades, leading to unexpected transaction failures or a denial of service for legitimate traders. This mechanism is also susceptible to manipulation if an attacker can temporarily reduce reserves to block trading.
IssueThe `_transfer` function imposes dynamic limits on buy and sell transactions, restricting them to `amount <= reserveThis / 10` (10% of the token's reserve in the Uniswap pair). This dynamic cap, while potentially intended to prevent large price impacts, makes trading highly dependent on current liquidity. If reserves are low, users might be unable to execute even small trades, leading to unexpected transaction failures or a denial of service for legitimate traders. This mechanism is also susceptible to manipulation if an attacker can temporarily reduce reserves to block trading.
FixRe-evaluate the necessity and implications of the dynamic `max cap buy/sell` limits. Consider implementing fixed limits or a more robust mechanism that ensures basic trading functionality even during low liquidity periods. Clearly document the behavior and potential consequences of this dynamic cap for users.
StatusUnresolved
Medium

Custom Uniswap V2 Math Deviation

M-03The `_getAmountOut` and `_getAmountIn` functions implement custom calculations for Uniswap V2-like swaps, using `9975` and `10000` for fee adjustments. This deviates from the standard Uniswap V2 fee of `0.3%` (typically represented as `997/1000` or `9970/10000`). While this might be an intentional design choice, it is non-standard and could lead to unexpected price impacts, arbitrage opportunities, or compatibility issues with external DeFi protocols that assume standard Uniswap V2 math.
IssueThe `_getAmountOut` and `_getAmountIn` functions implement custom calculations for Uniswap V2-like swaps, using `9975` and `10000` for fee adjustments. This deviates from the standard Uniswap V2 fee of `0.3%` (typically represented as `997/1000` or `9970/10000`). While this might be an intentional design choice, it is non-standard and could lead to unexpected price impacts, arbitrage opportunities, or compatibility issues with external DeFi protocols that assume standard Uniswap V2 math.
FixClearly document the reasons for deviating from standard Uniswap V2 math and the implications for users and integrators. Ensure that the custom calculations are thoroughly tested and verified to prevent unintended economic consequences. Consider aligning with standard Uniswap V2 math if the deviation does not offer a critical functional advantage.
StatusUnresolved
Low

Publicly Callable `updatePoolReserve` with Potential for Manipulation

L-01The `updatePoolReserve()` function can be called by any external address. Although it includes a time-based guard (`block.timestamp >= poolStatus.t + 1 hours`) to limit updates to once per hour, allowing public calls means an attacker could time their transaction to update the `poolStatus.bal` (USDT reserve) at a specific moment. Since `poolStatus.bal` directly influences the dynamic `max cap buy/sell` limits, this could be used to front-run or manipulate the perceived liquidity, potentially affecting legitimate trades.
IssueThe `updatePoolReserve()` function can be called by any external address. Although it includes a time-based guard (`block.timestamp >= poolStatus.t + 1 hours`) to limit updates to once per hour, allowing public calls means an attacker could time their transaction to update the `poolStatus.bal` (USDT reserve) at a specific moment. Since `poolStatus.bal` directly influences the dynamic `max cap buy/sell` limits, this could be used to front-run or manipulate the perceived liquidity, potentially affecting legitimate trades.
FixConsider restricting the `updatePoolReserve()` function to `onlyOwner` or a trusted role, or implementing a more robust mechanism to prevent malicious timing attacks. Alternatively, ensure that the impact of `poolStatus.bal` updates on trading limits is thoroughly analyzed for potential manipulation vectors.
StatusUnresolved
Low

Unused State Variables

L-02The state variables `yplusSwapAddress` and `interactionContract` are declared in the contract but are neither initialized in the constructor nor assigned values via any setter functions in the provided code. This indicates either incomplete implementation, dead code, or variables intended for future use without current functionality. Unused variables can lead to confusion, increase contract size unnecessarily, and potentially introduce vulnerabilities if they are later used without proper initialization or validation.
IssueThe state variables `yplusSwapAddress` and `interactionContract` are declared in the contract but are neither initialized in the constructor nor assigned values via any setter functions in the provided code. This indicates either incomplete implementation, dead code, or variables intended for future use without current functionality. Unused variables can lead to confusion, increase contract size unnecessarily, and potentially introduce vulnerabilities if they are later used without proper initialization or validation.
FixRemove unused state variables to reduce contract complexity and gas costs. If these variables are intended for future use, implement proper initialization in the constructor or secure setter functions, and clearly document their purpose.
StatusUnresolved
Info

Truncated Code Limits Audit Scope

I-01The provided source code for the `XPLUSToken` contract is incomplete. Specifically, the `_transfer` function is truncated, and critical logic related to `_swapAndDistribute()` and the full application of `totalProfitTaxRate` is missing. This significantly limits the ability to conduct a comprehensive security audit, as crucial functionality, potential vulnerabilities, and the complete economic model cannot be fully assessed.
IssueThe provided source code for the `XPLUSToken` contract is incomplete. Specifically, the `_transfer` function is truncated, and critical logic related to `_swapAndDistribute()` and the full application of `totalProfitTaxRate` is missing. This significantly limits the ability to conduct a comprehensive security audit, as crucial functionality, potential vulnerabilities, and the complete economic model cannot be fully assessed.
FixProvide the complete and untruncated source code for all relevant contracts to enable a thorough and accurate security audit. Without the full code, any audit findings are necessarily partial and may not cover all potential risks.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's ERC20, Ownable, and ReentrancyGuard, providing a solid security baseline (7.2 Code Security). However, the overridden `_transfer` function contains highly complex custom logic for tax calculations and fee distribution, which increases the attack surface and potential for errors (7.2 Code Security). The implementation of custom Uniswap V2 math functions (`_getAmountOut`, `_getAmountIn`) deviates from standard calculations, potentially leading to unexpected price impacts or arbitrage opportunities (7.4 Economic). Additionally, dynamic `max cap buy/sell` limits based on current reserves can cause unexpected transaction failures or liquidity issues (7.4 Economic). The `updatePoolReserve` function, though time-gated, is publicly callable, allowing external parties to influence state updates that affect trading limits (7.3 Access Control).

GovernanceHigh1/10

The tokenomics involve high buy (3.5%) and sell (3.5%) tax rates, with a complex distribution mechanism to various addresses and a burn address (7.4 Economic). The `totalProfitTaxRate` is declared but its application is missing from the provided code, indicating incomplete economic logic (7.4 Economic). The owner's ability to initiate the `presale` and thus enable trading is a critical centralized control point (7.5 Governance). Dynamic `max cap buy/sell` limits, tied to current liquidity, can create unpredictable trading conditions and potential for denial of service for legitimate users (7.4 Economic). A `coldTime` mechanism is implemented to prevent rapid selling, which impacts user liquidity (7.4 Economic).

UpgradesMedium6/10

The contract is not designed with upgradeability patterns (e.g., proxy contracts). Therefore, there are no upgrade-related risks (7.7 Upgrades). Any changes to the contract logic would require a new deployment and migration of assets.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

37.9% in top 10
6.3% in wallets31.6% in contracts
Effective Concentration19.0%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$21.1500 across 4 pairs
Pancakeswap v3USDTanalysed$2094.8%Uniswap v2USDT$15.1%Uniswap v2WBNB$00.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned35.3%
LP Locked35.3% · Null Address
Top-1 Unlocked Holder59.0%
Top-3 Unlocked64.7%

Key Addresses

5 addresses
Deployer
0x22ef…eaaa
Unlocked LP Held By
0xc603…eb070xd506…73560xe698…68bd0x0ed9…9706

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Liquidity < $10k ($21 across 4 pairs — easily drained)
  • LP top1 unlocked holder = 59.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • 1 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 2 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
Hana Token (HANA)High RiskUpstarty (UPY)High RiskOrizon (ORI)High Risk牛来 (NIULAI)High RiskRandyHigh RiskShopinX Token (SPX)High Risk

Would You Like a More Detailed Audit of XPULS?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit