Quantum Audit Logo
Launch App

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

Is TaleX Safe?

XBNB 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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance2/10Upgrades6/10Checks passed3 of 5Findings1 Low · 2 Info3
SummaryAI Copilot

The BEP40Token contract implements a standard fixed-supply token with basic ERC-20 functionalities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (68.9% total → 41.0% effective; 22.5% in EOAs, 46.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
46.4%Contracts22.5%Wallets31.1%Everyone else
46.4%Contracts22.5%Wallets31.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
68.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.4%
  • Walletsanonymous holders, free to sell22.5%
  • Everyone elsethe rest of the supply31.1%
Effective concentrationwhat the score reads41.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$496.4K across 3 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$496.4KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x7e07…a31d0x59ac…7deb0x4885…b1aa

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

Security Findings

1 Low2 Info
Low

Standard ERC-20 approve Race Condition

The approve function, as implemented in the ERC-20 standard, is susceptible to a race condition. If a user approves an amount for a spender, and then attempts to change that approved amount, a malicious spender could front-run the second approve transaction. This could result in the spender being able to spend both the original and the new approved amounts, effectively doubling their allowance.L-01

Issue

The approve function, as implemented in the ERC-20 standard, is susceptible to a race condition. If a user approves an amount for a spender, and then attempts to change that approved amount, a malicious spender could front-run the second approve transaction. This could result in the spender being able to spend both the original and the new approved amounts, effectively doubling their allowance.

Fix

While the contract provides increaseAllowance and decreaseAllowance to mitigate this issue, users might still interact directly with the approve function. Educate users to always use increaseAllowance and decreaseAllowance when modifying an existing allowance. If approve must be used, advise users to first set the allowance to zero before setting a new non-zero allowance.

Status

Unresolved

Info

Redundant SafeMath Usage in Solidity 0.8.x

Solidity versions 0.8.0 and higher include built-in overflow and underflow checks for all arithmetic operations by default. The explicit use of the SafeMath library in this contract is therefore redundant. While it does not introduce a vulnerability, it adds unnecessary gas overhead and increases code complexity.I-01

Issue

Solidity versions 0.8.0 and higher include built-in overflow and underflow checks for all arithmetic operations by default. The explicit use of the SafeMath library in this contract is therefore redundant. While it does not introduce a vulnerability, it adds unnecessary gas overhead and increases code complexity.

Fix

Remove the SafeMath library and its using SafeMath for uint256; directive. Rely on Solidity's native checked arithmetic for uint256 operations. This will reduce gas costs and simplify the codebase.

Status

Unresolved

Info

Redundant Public Variable Getter

The _decimals state variable is declared as public, which automatically generates a public getter function decimals(). The contract then explicitly defines another external function decimals() that returns the same _decimals value. This creates a redundant function.I-02

Issue

The _decimals state variable is declared as public, which automatically generates a public getter function decimals(). The contract then explicitly defines another external function decimals() that returns the same _decimals value. This creates a redundant function.

Fix

Remove the explicitly defined decimals() external function. The public _decimals variable already provides the necessary getter. Alternatively, if an explicit external function is preferred, declare _decimals as internal or private.

Status

Unresolved

Analysis

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

The BEP40Token contract implements a standard fixed-supply token with basic ERC-20 functionalities. The contract utilizes SafeMath for arithmetic operations and includes functions for transfer, approval, and burning. The initial token supply is minted to the deployer in the constructor. The overall design is straightforward, and no critical vulnerabilities were identified. Minor informational and low-severity issues related to code redundancy and standard ERC-20 patterns were noted.

Technical10/10Low risk

The technical architecture (7.1) of the BEP40Token contract is a standard implementation of a fixed-supply token, providing expected functionalities like transfer and approval. Code security (7.2) is generally robust, with the use of SafeMath, although redundant in Solidity 0.8.x, preventing direct integer overflows. Access control (7.3) is minimal, with no administrative roles for token management post-deployment, which aligns with a simple, immutable token design. A minor issue is the standard ERC-20 approve race condition (L-01), though increaseAllowance and decreaseAllowance functions are provided to mitigate this.

Governance2/10High risk

The contract represents a simple token with no complex economic models or governance mechanisms (7.4, 7.5). The entire token supply is minted to the deployer during construction, establishing a fixed supply without further minting capabilities. This design choice simplifies the economic model and removes risks associated with dynamic supply changes or complex governance structures. There are no external dependencies (7.6) that could introduce economic or governance risks.

Upgrades6/10Medium risk

The BEP40Token contract is not designed as an upgradeable proxy (7.7). It is a standard, immutable contract, meaning its logic cannot be changed after deployment. This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or malicious upgrade paths. However, it also means that any bugs or desired feature changes would require a new contract deployment and migration.

Final RecommendationWhat to do about this score

It is recommended to review and address the identified informational and low-severity findings to enhance code quality and user experience.

Specifically, consider removing redundant SafeMath usage and duplicate getter functions to optimize gas and readability. While the approve race condition is inherent to ERC-20, ensure users are aware of the safer increaseAllowance and decreaseAllowance methods. For future projects, consider using OpenZeppelin contracts as a robust and audited foundation.

Contract & Record

1 audit on record
TypeBEP40Token
NetworkBNB Chain
Token age1y
Contract0x0510…e776
Deployer0xa878…edf1
Badge for your website
TaleX 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, 202630Low
  2. Aug 15, 202628Low

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

Frequently Asked Questions

What is the X contract address?

The TaleX (X) contract on BNB Chain is 0x0510101ec6c49d24ed911f0011e22a0d697ee776. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is TaleX a scam?

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

Is X liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $496.4K.

Who holds X?

As of Sep 4, 2026, the 10 largest holders own 68.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
AsterBNB Chain30LowMYXBNB Chain30LowBluwhale AIBLUAI · BNB Chain30LowPeaqOFTPEAQ · BNB Chain30Low施工猫SUE · BNB Chain30LowVELLORAVELL · BNB Chain30Low

Would You Like a More Detailed Audit of TaleX?

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