Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Asteroid Shiba a Scam?

ASTEROIDEthereum
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance7/10Upgrades8/10Checks passed5 of 5Findings2 Critical · 1 High · 2 Medium · 1 Low · 2 Info8
SummaryAI Copilot

The Asteroid Shiba (AS) token contract is an ERC-20 token with significant owner privileges, including the ability to modify tax rates, transaction limits, and wallet size limits.

Read the full analysis
What raised the score
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Our automated scanner reviewed Asteroid Shiba (ASTEROID) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
9.4%Contracts13.5%Wallets77.0%Everyone else
9.4%13.5%Wallets77.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
23.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking9.4%
  • Walletsanonymous holders, free to sell13.5%
  • Everyone elsethe rest of the supply77.0%
Effective concentrationwhat the score reads17.3%
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 4$1.94M across 8 pairs
Show 2 more pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$1.27MShare of depth65.3%
LP Burned95.9% · ≈ permanent lock
LP Locked95.9% · Null Address
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.

Security Findings

2 Critical1 High2 Medium1 Low2 Info
Critical

Extreme Centralization and Owner Privileges

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

Issue

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

Fix

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

Status

Unresolved

Critical

Honeypot Potential

Due 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.C-02

Issue

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

Fix

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

Status

Unresolved

High

Anti-Bot/Anti-Whale Mechanisms Bypass

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

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of Event Emission for Critical State Changes

Many 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Potential for Stuck ETH in Swap Mechanism

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

Issue

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

Fix

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

Status

Unresolved

Low

Unchecked Return Values for External Calls

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

Issue

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

Fix

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

Status

Unresolved

Info

Redundant SafeMath Library

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

Issue

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

Fix

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

Status

Unresolved

Info

Hardcoded Uniswap Router Address

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

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Asteroid Shiba (AS) token contract is an ERC-20 token with significant owner privileges, including the ability to modify tax rates, transaction limits, and wallet size limits. This high degree of centralization introduces critical risks, including the potential for a honeypot scenario where the owner could prevent users from selling or impose prohibitive taxes. While the contract implements anti-bot and anti-whale measures, these can be bypassed by the owner. The use of SafeMath is redundant in Solidity 0.8.25, and a lack of event emissions for critical state changes reduces transparency.

Technical5/10Medium risk

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.

Governance7/10Low risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

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

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 & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age1y
Contract0xf280…4126
Deployer0x0557…2278
Badge for your website
Asteroid Shiba security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202620Low

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

Frequently Asked Questions

Is Asteroid Shiba a scam?

Based on available on-chain data, Asteroid Shiba exhibits characteristics that typically differentiate it from common scam projects. The contract is verified, ownership has been renounced, and no mint function exists, which collectively reduce the risk of rug pulls or unauthorized token creation by the deployer. These factors suggest a degree of technical robustness and transparency.

Is Asteroid Shiba safe to buy?

Asteroid Shiba features several safety measures, including locked liquidity and renounced ownership, which contribute to its low-risk score of 0/100 from a contract security standpoint. However, no cryptocurrency investment is entirely without risk. Investors should be aware of the 13.7% token concentration among the top 10 holders and the inherent volatility of the crypto market.

Has Asteroid Shiba been audited?

The provided data indicates the Asteroid Shiba contract is 'verified,' meaning its source code is publicly available and matches the deployed bytecode on the Ethereum blockchain. While this promotes transparency, it is distinct from a formal security audit conducted by an independent third party, which would typically involve a deeper code review for vulnerabilities.

Related Audits

6 more on the recordAll audits
TurboEthereum20LowBook of EthereumBOOE · Ethereum21LowsatoEthereum19LowclausEthereum21LowPepes DogZEUS · Ethereum18LowTsutsuji the CateCATE · Ethereum22Low

Would You Like a More Detailed Audit of Asteroid Shiba?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page