Quantum Audit Logo

Is Baby Ansem a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Baby Ansem BABYANSEM
0x67ee…6666
BNB Chain Not verifiedLast checked 2d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BabyAnsem ERC20 token contract exhibits a critical flaw where no mechanism exists to mint or initialize the token supply. This renders the token completely non-functional, as `_totalSupply` and all account balances will perpetually remain zero, preventing any transfers. Additionally, the contract uses a non-standard decimal value and the `approve` function carries inherent ERC20 race condition risks.

1 Critical1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$6.0600
Liquidity
$12.9K
Price
$0.
Token Age
3d
Top 10 Holders
89.3%

Security Findings

1 Crit1 Low1 Info
Critical

Unmintable Token Supply Renders Contract Non-Functional

C-01The `ERC20` contract lacks any mechanism to mint new tokens or set an initial supply. The `_totalSupply` variable is private and never increased, and there is no `_mint` function or constructor logic to populate `_balances`. Consequently, `_totalSupply` will always be zero, and all account balances (`_balances`) will remain zero. Any attempt to `transfer` or `transferFrom` an `amount` greater than zero will revert due to `fromBalance >= amount` check failing, making the token completely unusable.
IssueThe `ERC20` contract lacks any mechanism to mint new tokens or set an initial supply. The `_totalSupply` variable is private and never increased, and there is no `_mint` function or constructor logic to populate `_balances`. Consequently, `_totalSupply` will always be zero, and all account balances (`_balances`) will remain zero. Any attempt to `transfer` or `transferFrom` an `amount` greater than zero will revert due to `fromBalance >= amount` check failing, making the token completely unusable.
FixImplement a `_mint` function (e.g., in the constructor or via a controlled function) to set an initial token supply and update `_totalSupply` and `_balances`. For example, add `_mint(_msgSender(), initialSupply);` to the constructor, or create a privileged `mint` function.
StatusUnresolved
Low

ERC20 `approve` Race Condition Risk

L-01The standard ERC20 `approve` function is susceptible to a known front-running attack. If an owner increases an allowance from X to Y, a malicious spender could observe the transaction, spend the original X amount, and then front-run the owner's transaction to approve Y, effectively spending X+Y. This risk is explicitly mentioned in the ERC20 interface comments.
IssueThe standard ERC20 `approve` function is susceptible to a known front-running attack. If an owner increases an allowance from X to Y, a malicious spender could observe the transaction, spend the original X amount, and then front-run the owner's transaction to approve Y, effectively spending X+Y. This risk is explicitly mentioned in the ERC20 interface comments.
FixWhile this is an inherent ERC20 design pattern, users should be advised to use `increaseAllowance` and `decreaseAllowance` functions when modifying existing allowances, as these mitigate the race condition by atomically adjusting the allowance relative to its current value.
StatusUnresolved
Info

Non-Standard Decimals Value

I-01The `decimals()` function returns `9`. While technically valid, the vast majority of ERC20 tokens, especially those mimicking Ether, use `18` decimals. This non-standard value can lead to display issues in wallets, exchanges, and other DeFi platforms that might default to 18 decimals, potentially misrepresenting token values to users.
IssueThe `decimals()` function returns `9`. While technically valid, the vast majority of ERC20 tokens, especially those mimicking Ether, use `18` decimals. This non-standard value can lead to display issues in wallets, exchanges, and other DeFi platforms that might default to 18 decimals, potentially misrepresenting token values to users.
FixConsider changing the `decimals()` function to return `18` for better compatibility and consistency with the broader ERC20 ecosystem. If `9` is intentional, ensure all integrations are aware of this specific value.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages a structure similar to OpenZeppelin's ERC20 implementation, benefiting from Solidity 0.8.x's built-in overflow/underflow protections. However, a critical architectural flaw (7.1 Architecture) prevents the token from ever having a supply, as `_totalSupply` is never initialized or increased, making all transfers impossible. The `decimals()` function (7.2 Code Security) returns 9, which is non-standard for ERC20 tokens.

GovernanceMedium4/10

The contract is a basic ERC20 token with no complex governance or economic mechanisms (7.5 Governance, 7.4 Economic). Its simplicity inherently reduces risks associated with intricate protocol interactions or privileged roles. There are no specific economic incentives or governance structures to analyze for vulnerabilities.

UpgradesLow8/10

This contract is not implemented as an upgradeable proxy (7.7 Upgrades). Therefore, it does not carry the specific risks associated with proxy patterns, such as storage collisions or improper initialization. Once deployed, its logic is immutable.

Security Checklist

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

Holder Composition

89.3% in top 10
10.7% in wallets78.6% in contracts
Effective Concentration42.2%

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

$12.9K

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

3 addresses
Deployer
0xd10b…5215
Unlocked LP Held By
0x1e78…71400x0ed9…9706

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

What Raised This Score

8 factors
  • Top-10 concentration > 30% (89.3% total → 42.2% effective; 10.7% in EOAs, 78.6% in contracts — moderate)
  • Liquidity < $50k ($12,886 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • LP claimed locked but only 0.0% actually locked
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 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
EVAAHigh RiskBubblemaps (BMT)High RiskPIZZAHigh RiskDGrid AI (DGAI)High RiskStupid Kid (傻孩子)High RiskChainOpera AI (COAI)High Risk

Would You Like a More Detailed Audit of Baby Ansem?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit