Quantum Audit Logo

Is Xeleb AI Safe?

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

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

Xeleb AI XCX
0xe32f…8eaf
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The TokenERC20 contract is a standard ERC-20 token implementation, inheriting from OpenZeppelin's battle-tested ERC20 and ERC20Burnable contracts. The code quality is high, and no critical or high-severity vulnerabilities were identified. The primary considerations are related to the initial centralized token distribution, the non-upgradeable nature of the contract, and the inherent race condition in the standard ERC-20 `approve` function.

1 Low2 Informational
Volume 24h
$64.3K
Liquidity
$75.5K
Price
$0.003746
Token Age
1y
Top 10 Holders
96.2%

Security Findings

1 Low2 Info
Low

Standard ERC-20 `approve` Race Condition

L-01The standard ERC-20 `approve` function, as implemented in OpenZeppelin's ERC20, is susceptible to a known front-running vulnerability. If a user attempts to change an existing allowance from `X` to `Y` (where `Y` is not 0), a malicious actor observing this transaction could front-run it by spending the original `X` allowance before the new `Y` allowance is set. This could lead to the malicious actor effectively spending `X + Y` tokens instead of just `Y`, if the user's intent was to replace `X` with `Y`.
IssueThe standard ERC-20 `approve` function, as implemented in OpenZeppelin's ERC20, is susceptible to a known front-running vulnerability. If a user attempts to change an existing allowance from `X` to `Y` (where `Y` is not 0), a malicious actor observing this transaction could front-run it by spending the original `X` allowance before the new `Y` allowance is set. This could lead to the malicious actor effectively spending `X + Y` tokens instead of just `Y`, if the user's intent was to replace `X` with `Y`.
FixUsers should be advised to always set the allowance to zero (`approve(spender, 0)`) before setting a new non-zero allowance to mitigate this specific race condition. Alternatively, for more robust allowance management, consider using `increaseAllowance` and `decreaseAllowance` functions (if implemented in a custom ERC20 extension), which are designed to prevent this type of front-running attack.
StatusUnresolved
Info

Centralized Initial Token Distribution

I-01The `TokenERC20` contract's constructor mints the entire `_totalSupply` to `msg.sender` (the deployer). This design choice results in a highly centralized initial distribution, where the deployer holds 100% of the token supply. This concentration of tokens can pose risks related to market manipulation, single points of failure, or perceived lack of decentralization.
IssueThe `TokenERC20` contract's constructor mints the entire `_totalSupply` to `msg.sender` (the deployer). This design choice results in a highly centralized initial distribution, where the deployer holds 100% of the token supply. This concentration of tokens can pose risks related to market manipulation, single points of failure, or perceived lack of decentralization.
FixProjects should consider a more decentralized distribution strategy for the initial token supply. This could involve mechanisms such as airdrops, liquidity pool provisioning, vesting schedules, or multi-signature controlled treasuries to distribute tokens among multiple stakeholders or the community. This is a design decision that impacts economic governance and project perception.
StatusUnresolved
Info

Non-Upgradeable Contract Design

I-02The `TokenERC20` contract is deployed as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified or updated. Any discovered vulnerabilities, desired feature enhancements, or changes to the token's behavior would require deploying a new contract and migrating all users and assets, which can be a complex and costly process.
IssueThe `TokenERC20` contract is deployed as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified or updated. Any discovered vulnerabilities, desired feature enhancements, or changes to the token's behavior would require deploying a new contract and migrating all users and assets, which can be a complex and costly process.
FixFor projects with long-term aspirations or those that anticipate evolving requirements, consider implementing an upgradeable proxy pattern (e.g., UUPS, Transparent) from OpenZeppelin. This would allow for future bug fixes, optimizations, or feature additions without requiring a full redeployment and migration, enhancing the project's longevity and adaptability.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract leverages OpenZeppelin's well-audited ERC20 and ERC20Burnable implementations, which significantly reduces the risk of common technical vulnerabilities (7.1 Architecture, 7.2 Code Security). Standard ERC-20 functions are correctly implemented, and arithmetic operations are protected against overflow/underflow through Solidity's default checks and OpenZeppelin's careful use of `unchecked` blocks. Access control (7.3 Access Control) is limited to standard ERC-20 permissions, with no additional roles, which aligns with a simple token design. No reentrancy or external call issues were found.

GovernanceHigh1/10

The contract's economic model (7.4 Economic) involves an initial total supply minted entirely to the deployer, leading to a centralized distribution. While common for new tokens, this implies the deployer holds significant control over the token's initial market dynamics. There is no explicit governance mechanism (7.5 Governance) beyond the deployer's initial control. No oracle dependencies (7.6 External) or complex economic interactions are present, simplifying the economic risk profile.

UpgradesMedium6/10

The TokenERC20 contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice means that its logic cannot be modified post-deployment. While this eliminates upgrade-related risks, it also means any future bug fixes or feature enhancements would necessitate a new contract deployment and asset migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

96.2% in top 10
32.2% in wallets64.0% in contracts
Effective Concentration57.8%

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

$118.3K across 2 pairs
Pancakeswap v3USDTanalysed$75.5K63.8%UniswapUSDT$42.8K36.2%

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

Top-1 Unlocked Holder70.6%
Top-3 Unlocked82.7%

Key Addresses

11 addresses
Deployer
0x8f5c…a077
Unlocked LP Held By
0x2fbe…da9a0xfeee…2fb80x4cc4…2ee20xf999…153f0x2799…64c30x5ad1…2cb00xceab…58be0x1498…d27e0xa86d…dfc30x611c…fba1

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 status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (96.2% total → 57.8% effective; 32.2% in EOAs, 64.0% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 70.6% (independent LP — depth risk, pool = 64% of DEX liquidity)
  • LP top3 unlocked holders = 82.7% (independent LP — depth risk, pool = 64% of DEX liquidity)
  • 1 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
ARKMedium Risk牛来Medium RiskSaturnMedium RiskMax Sister (LILY)Medium RiskTrusta.AI (TA)Medium RiskMeta Financial AI (MEFAI)Medium Risk

Would You Like a More Detailed Audit of Xeleb AI?

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

Get Detailed Audit