Is Baby Ansem (BABYANSEM) a Scam? New Token Security Check

Critical Security Flags

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Audit History

2 audits on record

Jul 2351

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: It is critical to address the fundamental flaw preventing token supply initialization. Implement a `_mint` function or an initial supply mechanism within the constructor to ensure the token is functional. Additionally, consider aligning the `decimals()` value with common ERC20 standards (e.g., 18) for better ecosystem compatibility and user experience. Users should be aware of the inherent `approve` race condition risk.

Category Ratings

TechnicalLow

8/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 in

GovernanceMedium

4/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 ana

UpgradesLow

8/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.

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

8 factors

Top-10 concentration > 30% (88.3% total → 42.3% effective; 11.7% in EOAs, 76.6% in contracts — moderate)
Liquidity < $50k ($10,180 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

Security Findings

3 total

1 Critical 1 Low 1 Info

C-01CriticalUnresolved

Unmintable Token Supply Renders Contract Non-Functional

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

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

L-01LowUnresolved

ERC20 `approve` Race Condition Risk

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

Recommendation: While 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.

I-01InformationalUnresolved

Non-Standard Decimals Value

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

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

Is Baby Ansem a Scam? BABYANSEM