Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Asteroid Shiba a Scam?

ASTEROIDBNB Chain
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance5/10Upgrades3/10Checks passed3 of 5Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a multi-stage tax mechanism.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 85.8%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 85.8% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 2 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 BNB Chain. 3 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
20.0%Contracts7.2%Wallets72.8%Everyone else
20.0%Contracts7.2%72.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
27.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking20.0%
  • Walletsanonymous holders, free to sell7.2%
  • Everyone elsethe rest of the supply72.8%
Effective concentrationwhat the score reads15.2%
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$127.2K across 6 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$122.3KShare of depth96.2%
Top-1 Unlocked Holder39.9%
Top-3 Unlocked85.8%
Unlocked LP held by
0xaaf2…a6010xbb29…b3360xef7c…22c20x1262…3df00xa395…f4570x4157…63e40x8e0a…76c10x1c12…77ef0x611c…fba10xb262…eeed

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

Security Findings

1 Critical2 High2 Medium1 Low1 Info
Critical

Missing Critical Function Implementation (_processTax)

The _processTax internal function, which is responsible for handling and distributing collected taxes, is called within _liquidateTax but its implementation is not provided in the source code. This function is central to the token's economic model and its absence prevents a full security assessment of the tax mechanism, potentially hiding severe vulnerabilities such as reentrancy, incorrect distribution, or stuck funds.C-01

Issue

The _processTax internal function, which is responsible for handling and distributing collected taxes, is called within _liquidateTax but its implementation is not provided in the source code. This function is central to the token's economic model and its absence prevents a full security assessment of the tax mechanism, potentially hiding severe vulnerabilities such as reentrancy, incorrect distribution, or stuck funds.

Fix

Provide the complete and verified source code for the _processTax function. This function must be thoroughly audited for reentrancy, integer overflows/underflows, correct fund handling, and interaction with external contracts (ITaxProcessor, IDividend, v2Router).

Status

Unresolved

High

Centralized Token Supply

During initialization, the entire maxSupply of tokens is minted to the msg.sender (the contract owner). This grants the owner 100% of the token supply, enabling potential market manipulation, rug pulls, or other adverse economic impacts if not managed transparently and securely. This level of centralization poses a significant risk to token holders and the protocol's integrity.H-01

Issue

During initialization, the entire maxSupply of tokens is minted to the msg.sender (the contract owner). This grants the owner 100% of the token supply, enabling potential market manipulation, rug pulls, or other adverse economic impacts if not managed transparently and securely. This level of centralization poses a significant risk to token holders and the protocol's integrity.

Fix

Implement a clear and transparent token distribution strategy. This could involve vesting schedules, multi-signature wallets for large holdings, or mechanisms for decentralized distribution to mitigate the risks associated with a single entity holding the entire supply.

Status

Unresolved

High

Potential Denial of Service from _processTax

The _liquidateTax function is called at the beginning of every _transfer operation. If the unimplemented _processTax function (which is called by _liquidateTax) were to revert for any reason (e.g., due to an issue in an external call, insufficient funds, or a bug), all subsequent _transfer operations would be blocked. This would lead to a complete denial of service for all token holders, preventing any token movements.H-02

Issue

The _liquidateTax function is called at the beginning of every _transfer operation. If the unimplemented _processTax function (which is called by _liquidateTax) were to revert for any reason (e.g., due to an issue in an external call, insufficient funds, or a bug), all subsequent _transfer operations would be blocked. This would lead to a complete denial of service for all token holders, preventing any token movements.

Fix

Ensure the _processTax function is robust and handles all potential failure scenarios gracefully. Consider implementing error handling mechanisms, such as try-catch blocks for external calls, or a circuit breaker pattern to temporarily disable tax processing without halting all transfers if a critical issue arises. Thoroughly test _processTax under various conditions, including low liquidity or external contract failures.

Status

Unresolved

Medium

Immutability of Key External Contract Addresses

Critical external contract addresses such as taxProcessor, dividendContract, v2Router, quoteToken, and mainPool are set only during the initialize function and lack owner-controlled setter functions. This means if any of these external dependencies need to be updated (e.g., due to an exploit, deprecation, or upgrade of the external service), the FlapTaxTokenV3 contract itself would require an upgrade, which is a more complex, costly, and potentially risky operation than a simple setter function.M-01

Issue

Critical external contract addresses such as taxProcessor, dividendContract, v2Router, quoteToken, and mainPool are set only during the initialize function and lack owner-controlled setter functions. This means if any of these external dependencies need to be updated (e.g., due to an exploit, deprecation, or upgrade of the external service), the FlapTaxTokenV3 contract itself would require an upgrade, which is a more complex, costly, and potentially risky operation than a simple setter function.

Fix

Consider implementing onlyOwner setter functions for these critical external contract addresses. This would allow for greater operational flexibility and responsiveness to changes in the ecosystem without necessitating a full contract upgrade.

Status

Unresolved

Medium

Reliance on block.timestamp for Critical State Transitions

The _liquidateTax function uses block.timestamp to determine taxExpirationTime and antiFarmerExpirationTime and to trigger state changes (e.g., PoolState.TaxFree, PoolState.TaxEnforced). While common, block.timestamp can be manipulated by miners within a certain range (e.g., up to 900 seconds on Ethereum). This could allow miners or sophisticated attackers to front-run or back-run state transitions if the exact timing has significant economic implications, potentially exploiting tax rate changes or anti-farmer durations.M-02

Issue

The _liquidateTax function uses block.timestamp to determine taxExpirationTime and antiFarmerExpirationTime and to trigger state changes (e.g., PoolState.TaxFree, PoolState.TaxEnforced). While common, block.timestamp can be manipulated by miners within a certain range (e.g., up to 900 seconds on Ethereum). This could allow miners or sophisticated attackers to front-run or back-run state transitions if the exact timing has significant economic implications, potentially exploiting tax rate changes or anti-farmer durations.

Fix

While block.timestamp is often the only available time source, be aware of its manipulability. If precise, unmanipulable timing is critical for economically sensitive state transitions, consider alternative mechanisms like Chainlink Keepers or a time oracle, or ensure that the economic impact of minor time manipulation is acceptable.

Status

Unresolved

Low

Complex State Machine Logic

The contract implements a multi-stage PoolState machine (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with intricate transition logic, especially within _liquidateTax and _transfer. Such complexity increases the likelihood of subtle logic errors or unexpected behavior, even with thorough testing, and can make the contract harder to reason about and maintain.L-01

Issue

The contract implements a multi-stage PoolState machine (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with intricate transition logic, especially within _liquidateTax and _transfer. Such complexity increases the likelihood of subtle logic errors or unexpected behavior, even with thorough testing, and can make the contract harder to reason about and maintain.

Fix

Ensure comprehensive unit and integration tests cover all possible state transitions and edge cases within the PoolState machine. Consider adding clear Natspec documentation for each state and transition condition to improve clarity and maintainability.

Status

Unresolved

Info

Gas Overhead from _liquidateTax on Every Transfer

The _liquidateTax function is invoked at the beginning of every _transfer call. This design choice ensures timely tax processing and state updates but adds a fixed gas overhead to every token transfer, regardless of whether tax is actually collected or liquidated in that specific transaction. For high-frequency transfers, this could lead to higher transaction costs for users.I-01

Issue

The _liquidateTax function is invoked at the beginning of every _transfer call. This design choice ensures timely tax processing and state updates but adds a fixed gas overhead to every token transfer, regardless of whether tax is actually collected or liquidated in that specific transaction. For high-frequency transfers, this could lead to higher transaction costs for users.

Fix

This is a design trade-off. If gas efficiency becomes a significant concern, consider alternative mechanisms for triggering tax liquidation, such as a periodic onlyOwner call or a pull-based system, though this might introduce other complexities or delays in tax processing.

Status

Unresolved

Analysis

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

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a multi-stage tax mechanism. A critical finding is the absence of the _processTax function's implementation, which is central to the token's economic model and prevents a full security assessment of tax handling. Other significant risks include the highly centralized initial token supply and the potential for denial of service if the _processTax function were to revert. The contract utilizes OpenZeppelin's upgradeable patterns and standard ERC20 features.

Technical5/10Medium risk

The technical architecture (7.1) is complex due to its multi-state tax machine, increasing the surface for logic errors. A critical code security (7.2) issue is the missing implementation of the _processTax function, which is vital for tax distribution and could hide severe vulnerabilities like reentrancy or stuck funds. This also introduces a high risk of denial of service (7.8) if _processTax were to revert. The contract correctly uses OpenZeppelin libraries for standard ERC20 and upgradeability features, enhancing code quality.

Governance5/10Medium risk

The economic model (7.4) presents a high risk due to the entire maxSupply being minted to the owner during initialization, leading to extreme centralization and potential market manipulation. Access control (7.3) is heavily reliant on the owner for critical state transitions (startMigration, finalizeMigration). Key external contract addresses (taxProcessor, dividendContract, v2Router, quoteToken, mainPool) are immutable after initialization, requiring a contract upgrade for any changes, which is an operational (7.8) inflexibility. The reliance on block.timestamp for state transitions (7.2) introduces a medium risk of miner manipulation.

Upgrades3/10High risk

The contract is designed for upgradeability (7.7) using OpenZeppelin's Initializable and Upgradeable patterns, including _disableInitializers() in the constructor. This indicates a UUPS proxy pattern is likely intended, allowing the owner to manage upgrades. The use of PackedPoolState requires careful consideration during upgrades to avoid storage collisions, though OpenZeppelin's guidelines mitigate this risk if followed.

Final RecommendationWhat to do about this score

It is imperative to provide the complete source code for the _processTax function to enable a thorough security assessment of the core tax mechanism.

Address the high centralization of token supply by implementing a transparent and secure distribution strategy. Consider adding owner-controlled setter functions for critical external contract addresses to enhance operational flexibility without requiring full contract upgrades. Thoroughly test the complex state machine transitions and the _liquidateTax function to ensure robustness against edge cases and potential denial of service scenarios.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age14d
Contract0x3309…7777
Deployer0x1a11…66f4
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
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, 202665High
  2. Sep 4, 202663Medium
  3. Aug 15, 202650Medium

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

Related Audits

6 more on the recordAll audits
GoPlus SecurityGPS · BNB Chain65HighPro TokenPRO · BNB Chain64MediumXPULSBNB Chain66HighHana TokenHANA · BNB Chain66HighElonCoinBNB Chain64MediumUpstartyUPY · BNB Chain66High

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