Quantum Audit Logo

Is TaleX Safe?

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

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

TaleX X
0x0510…e776
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Low2 Informational
Volume 24h
$129.0K
Liquidity
$496.4K
Price
$0.009001
Token Age
1y
Top 10 Holders
68.9%

Security Findings

1 Low2 Info
Low

Standard ERC-20 `approve` Race Condition

L-01The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Info

Redundant SafeMath Usage in Solidity 0.8.x

I-01Solidity 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.
IssueSolidity 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.
FixRemove 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.
StatusUnresolved
Info

Redundant Public Variable Getter

I-02The `_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.
IssueThe `_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.
FixRemove 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`.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceHigh2/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

68.9% in top 10
22.5% in wallets46.4% in contracts
Effective Concentration41.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

$496.4K across 3 pairs
Pancakeswap v3WBNBanalysed$496.4K100.0%Pancakeswap v3USDT$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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xa878…edf1
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.

What Raised This Score

6 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

Related Audits

6 more on the record
AsterMedium RiskMYXMedium RiskBluwhale AI (BLUAI)Medium RiskPeaqOFT (PEAQ)Medium Risk施工猫 (SUE)Medium RiskmubarakMedium Risk

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