The audit of the BabyAsteroid token contract, an ERC20 implementation, identified a critical functional flaw: the token's total supply is permanently zero, rendering it non-functional. This issue prevents any tokens from being minted or transferred. Other findings include a non-standard decimals value and an informational note regarding the ERC20 approve race condition.

On-chain security analysis — is it a scam or legit?
Is Baby Asteroid Safe?
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 →The audit of the BabyAsteroid token contract, an ERC20 implementation, identified a critical functional flaw: the token's total supply is permanently zero, rendering it non-functional.
Read the full analysis- LP top1 unlocked holder = 100.0%
- LP top3 unlocked holders = 100.0%
- LP claimed locked but only 0.0% actually locked
- 1 Critical finding(s) from audit
- 1 Low finding(s) from audit
Exact factors
- 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
- 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 Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking17.1%
- Walletsanonymous holders, free to sell2.9%
- Everyone elsethe rest of the supply80.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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x1e78…71400x0ed9…9706No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalToken Supply Always Zero, Rendering Token Non-Functional
The ERC20 contract's _totalSupply variable is declared but never initialized in the constructor, nor is there any _mint function provided within the contract to increase this supply. Consequently, totalSupply() will always return 0, and no tokens can ever be created or transferred. This makes the token completely non-functional and unusable.C-01
Issue
The ERC20 contract's _totalSupply variable is declared but never initialized in the constructor, nor is there any _mint function provided within the contract to increase this supply. Consequently, totalSupply() will always return 0, and no tokens can ever be created or transferred. This makes the token completely non-functional and unusable.
Fix
Implement a _mint function, typically restricted to an owner or deployer, to allow for the creation of new tokens. Alternatively, initialize _totalSupply and mint an initial supply to a designated address within the constructor. Ensure that the _balances mapping is updated accordingly during minting.
Status
Unresolved
LowNon-Standard Decimals Value
The decimals() function returns a value of 9. While technically valid, the common standard for ERC20 tokens is 18 decimals, mimicking Ethereum's Wei. Deviating from this standard can lead to display inconsistencies or misinterpretations in wallets, exchanges, and DApps that assume 18 decimals.L-01
Issue
The decimals() function returns a value of 9. While technically valid, the common standard for ERC20 tokens is 18 decimals, mimicking Ethereum's Wei. Deviating from this standard can lead to display inconsistencies or misinterpretations in wallets, exchanges, and DApps that assume 18 decimals.
Fix
Consider changing the decimals() function to return 18 for better compatibility and user experience across the broader EVM ecosystem. If 9 decimals is an intentional design choice, ensure all front-end applications and integrations are aware of and correctly handle this value.
Status
Unresolved
InfoERC20 approve Race Condition Warning
The contract's comments correctly highlight the known race condition vulnerability associated with the approve function, where an attacker might exploit unfortunate transaction ordering to spend both the old and new allowance amounts. The contract provides increaseAllowance and decreaseAllowance as mitigations.I-01
approve Race Condition WarningIssue
The contract's comments correctly highlight the known race condition vulnerability associated with the approve function, where an attacker might exploit unfortunate transaction ordering to spend both the old and new allowance amounts. The contract provides increaseAllowance and decreaseAllowance as mitigations.
Fix
Educate users and integrated applications to prefer increaseAllowance and decreaseAllowance over directly calling approve when modifying an existing allowance. This helps prevent potential double-spend scenarios related to the approve race condition.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The contract is based on a standard ERC20 implementation, demonstrating good code structure and adherence to common patterns (7.1 Architecture, 7.2 Code Security). However, a critical functional flaw exists where the _totalSupply is never initialized or increased, and no _mint function is provided, making the token non-functional (C-01). The decimals() function returns 9, which is non-standard but not a vulnerability (L-01). The contract correctly includes increaseAllowance and decreaseAllowance to mitigate the approve race condition (I-01).
The contract implements a standard ERC20 token with no complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). The prefill indicates ownership is renounced, which eliminates central control risks and enhances decentralization (7.3 Access Control). Due to the critical functional flaw (C-01), the economic impact is currently zero as no tokens can exist or be traded.
The contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation, which simplifies its architecture and removes upgrade-related risks.
It is critical to address the functional flaw where the token's total supply remains zero.
This requires implementing a mechanism, such as a _mint function or initial minting in the constructor, to create and manage the token supply. Without this, the token is unusable. Additionally, consider aligning the decimals() value with the common ERC20 standard of 18 for better compatibility with ecosystem tools.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202627Low
- Aug 1, 202626Low
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Would You Like a More Detailed Audit of Baby Asteroid?
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