Is Asteroid Safe? Smart Contract Security Analysis

Security Findings

1 Crit3 Info

Critical

Unlocked Liquidity Pool

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

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

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

StatusUnresolved

Info

Incomplete Code Provided

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.

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

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

StatusUnresolved

Info

Redundant SafeMath Usage

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.

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

FixConsider 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+.

StatusUnresolved

Info

ERC20 `approve` Race Condition

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow9/10

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.

UpgradesLow9/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

25.4% in top 10

14.5% in wallets10.8% in contracts

Effective Concentration18.9%

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

$374.9K across 2 pairs

Uniswap v2WETHanalysed$345.8K Uniswap v3WETH$29.1K

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

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

3 addresses

Deployer

0xe843…2778

Unlocked LP Held By

0x3076…de3c0x1f2f…f387

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

What Raised This Score

1 factors

1 Critical 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

Is Asteroid Safe?

Security Findings

Unlocked Liquidity Pool

Incomplete Code Provided

Redundant SafeMath Usage

ERC20 `approve` Race Condition

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Asteroid?