Quantum Audit Logo
Launch App

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

Is XPULS Safe?

BNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades6/10Checks passed4 of 5Findings1 High · 3 Medium · 2 Low · 1 Info7
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Liquidity < $10k
  • LP top1 unlocked holder = 59.0%
  • 1 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
31.6%Contracts6.3%62.1%Everyone else
31.6%Contracts6.3%62.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
37.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking31.6%
  • Walletsanonymous holders, free to sell6.3%
  • Everyone elsethe rest of the supply62.1%
Effective concentrationwhat the score reads19.0%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$21.1500 across 4 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$20Share of depth94.8%
LP Burned35.3%
LP Locked35.3% · Null Address
Top-1 Unlocked Holder59.0%
Top-3 Unlocked64.7%
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.

Security Findings

1 High3 Medium2 Low1 Info
High

Centralization Risk via Owner Privileges and Immutable Setup

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

High and Complex Tax Mechanism with Incomplete Logic

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

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

The _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.M-02

Issue

The _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.

Fix

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

Status

Unresolved

Medium

Custom Uniswap V2 Math Deviation

The _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.M-03

Issue

The _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.

Fix

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

Status

Unresolved

Low

Publicly Callable updatePoolReserve with Potential for Manipulation

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Low

Unused State Variables

The 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.L-02

Issue

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

Fix

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

Status

Unresolved

Info

Truncated Code Limits Audit Scope

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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

Governance1/10High risk

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

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is highly recommended to complete and provide the full source code for a comprehensive audit, especially for the _transfer function and _swapAndDistribute logic.

Simplify the complex tax calculation and distribution logic within the _transfer function to reduce the risk of errors and improve maintainability. Re-evaluate the dynamic max cap buy/sell limits to ensure they do not inadvertently hinder legitimate trading or create opportunities for liquidity manipulation. Consider aligning Uniswap V2 math functions with standard implementations or clearly documenting the deviations and their implications.

Contract & Record

1 audit on record
TypeXPLUSToken
NetworkBNB Chain
Token age6mo
Contract0xabae…8228
Deployer0x22ef…eaaa
Badge for your website
XPULS security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202666High
  2. Jul 23, 202649Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the XPULS contract address?

The XPULS contract on BNB Chain is 0xabae909cd93bc2ddf90086f9aa6c3f8e154e8228. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is XPULS a scam?

Quantum Audit's risk score for XPULS is 66/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is XPULS liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $21.1500.

Who holds XPULS?

As of Sep 4, 2026, the 10 largest holders own 37.9% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Hana TokenHANA · BNB Chain66HighUpstartyUPY · BNB Chain66HighOrizonORI · BNB Chain66High牛来NIULAI · BNB Chain66HighRandyBNB Chain66HighShopinX TokenSPX · BNB Chain66High

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 Is this your token? Publish your own audit on this page