Is Asteroid Shiba (ASTEROID) a Scam? Security Analysis

Security Findings

2 Crit1 High2 Med1 Low2 Info

Critical

Extreme Centralization and Owner Privileges

C-01The contract owner possesses extensive control over nearly all critical parameters, including tax rates (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax), transaction limits (_maxTxAmount), wallet size limits (_maxWalletSize), swap thresholds (_taxSwapThreshold, _maxTaxSwap), anti-bot measures (sellsPerBlock, buysFirstBlock), and the ability to enable/disable trading (tradingOpen, swapEnabled). The owner can also whitelist addresses via the `isExile` mapping to bypass all restrictions. This level of centralization allows the owner to unilaterally alter the token's economic model and operational behavior, posing a severe risk to token holders.

IssueThe contract owner possesses extensive control over nearly all critical parameters, including tax rates (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax), transaction limits (_maxTxAmount), wallet size limits (_maxWalletSize), swap thresholds (_taxSwapThreshold, _maxTaxSwap), anti-bot measures (sellsPerBlock, buysFirstBlock), and the ability to enable/disable trading (tradingOpen, swapEnabled). The owner can also whitelist addresses via the `isExile` mapping to bypass all restrictions. This level of centralization allows the owner to unilaterally alter the token's economic model and operational behavior, posing a severe risk to token holders.

FixDecentralize control over critical parameters. Implement a multi-signature wallet for sensitive operations or introduce a time-locked governance mechanism for changes to tax rates, limits, and trading status. Remove the `isExile` mapping or restrict its use to only essential protocol addresses, not arbitrary user addresses.

StatusUnresolved

Critical

Honeypot Potential

C-02Due to the extreme centralization (C-01), the contract has significant honeypot potential. The owner can, at any time, set the sell tax to 100%, set the maximum transaction amount for sells to zero, or set the maximum wallet size to a value that prevents existing holders from selling. This would effectively trap user funds within the contract, making them unsellable and leading to total loss for investors.

IssueDue to the extreme centralization (C-01), the contract has significant honeypot potential. The owner can, at any time, set the sell tax to 100%, set the maximum transaction amount for sells to zero, or set the maximum wallet size to a value that prevents existing holders from selling. This would effectively trap user funds within the contract, making them unsellable and leading to total loss for investors.

FixImplement immutable tax rates and transaction limits, or subject any changes to a decentralized governance process with a time-lock. Ensure that minimum sell transaction amounts and maximum wallet sizes cannot be set to values that would prevent legitimate users from selling their tokens.

StatusUnresolved

High

Anti-Bot/Anti-Whale Mechanisms Bypass

H-01The contract implements anti-bot (e.g., `sellsPerBlock`, `buysFirstBlock`) and anti-whale (`_maxTxAmount`, `_maxWalletSize`) mechanisms. However, the `isExile` mapping, controlled by the owner, allows any address to bypass these restrictions. This means the owner can whitelist their own addresses or those of favored parties, rendering the anti-bot/anti-whale measures ineffective for those addresses and creating an unfair advantage or potential for manipulation.

IssueThe contract implements anti-bot (e.g., `sellsPerBlock`, `buysFirstBlock`) and anti-whale (`_maxTxAmount`, `_maxWalletSize`) mechanisms. However, the `isExile` mapping, controlled by the owner, allows any address to bypass these restrictions. This means the owner can whitelist their own addresses or those of favored parties, rendering the anti-bot/anti-whale measures ineffective for those addresses and creating an unfair advantage or potential for manipulation.

FixRe-evaluate the necessity and scope of the `isExile` mapping. If critical for protocol operations, restrict its use to only contract-internal addresses (e.g., router, treasury) and remove the owner's ability to add arbitrary user addresses. Ensure all users are subject to the same rules.

StatusUnresolved

Medium

Lack of Event Emission for Critical State Changes

M-01Many critical owner-controlled parameters, such as `_maxTxAmount`, `_maxWalletSize`, various tax rates, `swapEnabled`, `tradingOpen`, `sellsPerBlock`, `buysFirstBlock`, and `isExile` status, can be modified without emitting corresponding events. This lack of transparency makes it difficult for users and off-chain monitoring tools to track changes to the contract's behavior and economic model, increasing trust requirements.

IssueMany critical owner-controlled parameters, such as `_maxTxAmount`, `_maxWalletSize`, various tax rates, `swapEnabled`, `tradingOpen`, `sellsPerBlock`, `buysFirstBlock`, and `isExile` status, can be modified without emitting corresponding events. This lack of transparency makes it difficult for users and off-chain monitoring tools to track changes to the contract's behavior and economic model, increasing trust requirements.

FixEmit explicit events for every function that modifies a critical state variable. For example, `MaxTxAmountUpdated(uint256 newAmount)`, `TaxRatesUpdated(uint256 newBuyTax, uint256 newSellTax)`, `SwapEnabledToggled(bool status)`, `ExileStatusUpdated(address indexed account, bool isExiled)`. This improves transparency and auditability.

StatusUnresolved

Medium

Potential for Stuck ETH in Swap Mechanism

M-02The `swapAndLiquify` function transfers ETH to the `_taxWallet` after swapping tokens. If the `_taxWallet` address is a contract that does not have a `receive()` or `fallback()` function capable of accepting ETH, or if it reverts during the transfer, the entire swap operation could fail. This could lead to a denial of service for the automatic liquidity/tax collection mechanism, potentially accumulating tokens in the contract without being able to process them.

IssueThe `swapAndLiquify` function transfers ETH to the `_taxWallet` after swapping tokens. If the `_taxWallet` address is a contract that does not have a `receive()` or `fallback()` function capable of accepting ETH, or if it reverts during the transfer, the entire swap operation could fail. This could lead to a denial of service for the automatic liquidity/tax collection mechanism, potentially accumulating tokens in the contract without being able to process them.

FixImplement robust error handling for external ETH transfers. Consider adding a mechanism for the owner to recover stuck ETH from the contract if the `_taxWallet` becomes problematic. Ensure the `_taxWallet` is a reliable address or a contract designed to accept ETH.

StatusUnresolved

Low

Unchecked Return Values for External Calls

L-01The contract makes external calls to `IUniswapV2Factory.createPair` and `IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens` without explicitly checking their boolean return values. While Uniswap functions typically revert on failure, explicitly checking return values is a best practice to ensure expected behavior and prevent unexpected state. The `_approve` function is internal, but its usage in `transferFrom` relies on `SafeMath` for allowance checks.

IssueThe contract makes external calls to `IUniswapV2Factory.createPair` and `IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens` without explicitly checking their boolean return values. While Uniswap functions typically revert on failure, explicitly checking return values is a best practice to ensure expected behavior and prevent unexpected state. The `_approve` function is internal, but its usage in `transferFrom` relies on `SafeMath` for allowance checks.

FixExplicitly check the return values of external calls where applicable, especially for functions that return a boolean indicating success or failure. Although Uniswap functions often revert, defensive programming suggests checking for unexpected behavior.

StatusUnresolved

Info

Redundant SafeMath Library

I-01The contract uses the `SafeMath` library for arithmetic operations. However, the contract is compiled with Solidity 0.8.25, which includes built-in overflow and underflow checks by default. The use of `SafeMath` in this context is redundant and adds unnecessary gas overhead for each arithmetic operation.

IssueThe contract uses the `SafeMath` library for arithmetic operations. However, the contract is compiled with Solidity 0.8.25, which includes built-in overflow and underflow checks by default. The use of `SafeMath` in this context is redundant and adds unnecessary gas overhead for each arithmetic operation.

FixRemove the `SafeMath` library and directly use native arithmetic operators. Solidity 0.8.0 and later versions automatically handle overflow/underflow, making `SafeMath` obsolete for basic arithmetic.

StatusUnresolved

Info

Hardcoded Uniswap Router Address

I-02The Uniswap V2 Router address (0x7a25…488D) is hardcoded in the constructor. While this is common for mainnet deployments, it reduces flexibility. If the Uniswap router address changes in the future or if the contract were to be deployed on a different network with a different router address, the contract would need to be redeployed.

IssueThe Uniswap V2 Router address () is hardcoded in the constructor. While this is common for mainnet deployments, it reduces flexibility. If the Uniswap router address changes in the future or if the contract were to be deployed on a different network with a different router address, the contract would need to be redeployed.

FixConsider making the Uniswap router address configurable by the owner through a setter function, or pass it as a constructor argument. This would allow for greater flexibility and adaptability to future changes or multi-chain deployments.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract's technical architecture (7.1) is a standard ERC-20 implementation with added tax and anti-bot/anti-whale mechanisms. Code security (7.2) benefits from Solidity 0.8.25's built-in overflow checks, though SafeMath is redundantly used. However, the contract exhibits a lack of event emissions for critical state changes, such as modifications to tax rates or transaction limits, which hinders transparency. Additionally, there's a potential for the `swapAndLiquify` function to become stuck if the `_taxWallet` reverts during ETH transfer.

GovernanceLow7/10

The economic model (7.4) is highly centralized, granting the owner extensive control over all critical parameters, including buy/sell taxes, transaction limits, wallet size limits, and the ability to enable/disable trading. This level of control creates a significant honeypot risk, as the owner can manipulate these parameters to prevent users from selling their tokens or impose prohibitive taxes. The anti-bot and anti-whale mechanisms, while present, can be bypassed by the owner through the `isExile` mapping (7.3 Access Control), allowing whitelisted addresses to circumvent all restrictions. Governance (7.5) is entirely centralized with the `onlyOwner` modifier.

UpgradesLow8/10

The contract is not designed to be upgradeable (7.7). There are no proxy patterns or upgrade interfaces implemented, meaning the contract's logic is immutable once deployed. This eliminates upgrade-related risks but also prevents any future bug fixes or feature enhancements without a new deployment.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

23.0% in top 10

13.5% in wallets9.4% in contracts

Effective Concentration17.3%

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

$1.94M across 8 pairs

Uniswap v2WETHanalysed$1.27M Uniswap v4ETH$511.5K Uniswap v4USDC$102.8K Uniswap v3USDC$42.6K Uniswap v3WETH$9.0K Uniswap v3WETH$3.2K

Show 2 more pairsShow less

Uniswap v4USDC$1.5K Uniswap v4ETH$1.4K

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 Burned95.9% · ≈ permanent lock

LP Locked95.9% · Null Address

Key Addresses

10 addresses

Deployer

0x0557…2278

Unlocked LP Held By

0xcca0…8adc0xd9f8…b4b20x6481…6b5b0xc244…8a9e0x921c…5ce50x3144…fce30xeb0c…493f0x1f2f…f3870x563a…910f

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

What Raised This Score

4 factors

2 Critical finding(s) from audit
1 High finding(s) from audit
2 Medium 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

Final Recommendation

AI Copilot

Given the critical centralization risks and potential for a honeypot, users should exercise extreme caution.…

Read the verdictHide

It is strongly recommended to decentralize control over critical parameters by implementing a multi-signature wallet or a time-locked governance mechanism for sensitive functions. All critical state changes should emit events to ensure transparency and allow for off-chain monitoring. Consider removing the redundant SafeMath library to optimize gas usage. Thoroughly review and test all anti-bot and anti-whale mechanisms to ensure they function as intended and cannot be easily bypassed, especially by the owner.

Contract

TypeRouter, Token

Audit History

1 audit on record

Sep 420

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Is Asteroid Shiba a Scam?

Security Findings

Extreme Centralization and Owner Privileges

Honeypot Potential

Anti-Bot/Anti-Whale Mechanisms Bypass

Lack of Event Emission for Critical State Changes

Potential for Stuck ETH in Swap Mechanism

Unchecked Return Values for External Calls

Redundant SafeMath Library

Hardcoded Uniswap Router Address

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Asteroid Shiba?