On-chain security analysis — is it a scam or legit?
EthereumThe audit of the ASTEROID token contract (0xaff2565091e7207191dbe340b8528d02fa78d044) was conducted on an incomplete source code snippet.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x3076…de3c0x1f2f…f387No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The pre-analysis indicates the liquidity pool for the ASTEROID token is currently unlocked. This means that the deployer or liquidity provider can remove the entire liquidity at any time, potentially leading to a 'rug pull' and rendering the token worthless for other holders. This poses a severe economic risk to all token holders.
Implement a robust liquidity locking mechanism (e.g., using a reputable third-party locker like UniCrypt, Pinksale, or by sending LP tokens to a burn address or a time-locked contract) immediately after adding initial liquidity. This action is paramount for investor confidence and project legitimacy.
Unresolved
ERC20 contract implementation after the decimals() function. Critical functions like _mint, _transfer, _approve, and any custom logic (e.g., tax mechanisms, blacklisting, owner-controlled functions) are not visible. This significantly limits the scope and depth of the security assessment.I-01The provided contract source code was truncated, specifically the ERC20 contract implementation after the decimals() function. Critical functions like _mint, _transfer, _approve, and any custom logic (e.g., tax mechanisms, blacklisting, owner-controlled functions) are not visible. This significantly limits the scope and depth of the security assessment.
Provide the complete and verified source code for a comprehensive security audit. The current assessment is limited by the available information, and hidden vulnerabilities or centralized control mechanisms cannot be ruled out.
Unresolved
SafeMath library for arithmetic operations. While SafeMath prevents integer overflow/underflow, it is redundant in Solidity versions 0.8.0 and higher (the contract uses ^0.8.17) because the compiler automatically includes overflow/underflow checks for all arithmetic operations by default. Using SafeMath in 0.8+ can slightly increase gas costs without providing additional security benefits.I-02The contract uses the SafeMath library for arithmetic operations. While SafeMath prevents integer overflow/underflow, it is redundant in Solidity versions 0.8.0 and higher (the contract uses ^0.8.17) because the compiler automatically includes overflow/underflow checks for all arithmetic operations by default. Using SafeMath in 0.8+ can slightly increase gas costs without providing additional security benefits.
Consider removing the SafeMath library and relying on Solidity's native overflow/underflow checks for cleaner code and minor gas optimization. This will not compromise security in Solidity 0.8+.
Unresolved
approve Race Conditionapprove function is susceptible to a known race condition. If a user increases an allowance from X to Y and a malicious actor front-runs this transaction by spending X tokens, the subsequent approve(Y) transaction might allow the malicious actor to spend Y *additional* tokens, effectively spending X + Y instead of just Y.I-03The standard ERC20 approve function is susceptible to a known race condition. If a user increases an allowance from X to Y and a malicious actor front-runs this transaction by spending X tokens, the subsequent approve(Y) transaction might allow the malicious actor to spend Y *additional* tokens, effectively spending X + Y instead of just Y.
Users should be advised to first set the allowance to zero (approve(spender, 0)) before setting a new non-zero allowance. Developers can consider implementing increaseAllowance and decreaseAllowance functions (as in OpenZeppelin's ERC20) to mitigate this risk for users.
Unresolved
The audit of the ASTEROID token contract (0xaff2565091e7207191dbe340b8528d02fa78d044) was conducted on an incomplete source code snippet. A critical economic vulnerability was identified: the project's liquidity pool is currently unlocked, posing a significant rug pull risk. Technical aspects of the provided code snippet appear standard, utilizing SafeMath for arithmetic, though this is redundant in Solidity 0.8+.
The contract implements a standard ERC20 token using Solidity 0.8.17 and includes interfaces for Uniswap V2. The use of SafeMath for arithmetic operations ensures protection against integer overflows/underflows (7.2 Code Security), although this is redundant in Solidity versions 0.8.0 and higher. The provided code snippet is incomplete, limiting a full technical assessment (7.1 Architecture, 7.2 Code Security). No complex access control mechanisms or external interactions beyond standard ERC20 functions are visible in the provided portion (7.3 Access Control, 7.6 External).
A critical economic risk has been identified: the liquidity pool for the ASTEROID token is currently unlocked (7.4 Economic). This allows the liquidity provider to withdraw all funds, potentially leading to a complete loss for token holders. Without the full code, it's unclear if there are other owner-controlled functions that could impact token economics or governance (7.5 Governance). The project's long-term economic stability is severely jeopardized by the unlocked liquidity.
The contract is not designed as an upgradeable proxy, as indicated by is_proxy: false in the pre-analysis (7.7 Upgrades). This means the contract's logic cannot be modified after deployment. While this eliminates upgrade-related risks, it also means any discovered vulnerabilities or desired feature changes would require a new contract deployment and token migration.
It is critically important to lock the liquidity pool immediately using a reputable third-party service or by burning the LP tokens to prevent a potential rug pull.
A complete and verified source code should be provided for a thorough security audit to identify any hidden vulnerabilities or centralized control mechanisms. Additionally, consider removing redundant SafeMath usage for minor gas optimizations and be aware of the standard ERC20 approve race condition.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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
