Quantum Audit Logo

Is Asteroid Shiba a Scam?

Honeypot, rug-pull and ownership checks

Is this your token? Publish your own audit on this page →

Asteroid Shiba ASTEROID
0x3309…7777
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical2 High2 Medium1 Low1 Informational
i Our automated scanner reviewed Asteroid Shiba (ASTEROID) on BNB Chain. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$289.1K
Liquidity
$122.3K
Price
$0.0006237
Age
14d
Top 10 Holders
27.2%

Security Findings

1 Crit2 High2 Med1 Low1 Info
Critical

Missing Critical Function Implementation (`_processTax`)

C-01The `_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.
IssueThe `_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.
FixProvide 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`).
StatusUnresolved
High

Centralized Token Supply

H-01During 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.
IssueDuring 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.
FixImplement 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.
StatusUnresolved
High

Potential Denial of Service from `_processTax`

H-02The `_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.
IssueThe `_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.
FixEnsure 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.
StatusUnresolved
Medium

Immutability of Key External Contract Addresses

M-01Critical 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.
IssueCritical 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.
FixConsider 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.
StatusUnresolved
Medium

Reliance on `block.timestamp` for Critical State Transitions

M-02The `_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.
IssueThe `_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.
FixWhile `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.
StatusUnresolved
Low

Complex State Machine Logic

L-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Info

Gas Overhead from `_liquidateTax` on Every Transfer

I-01The `_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.
IssueThe `_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.
FixThis 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.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

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.

GovernanceMedium5/10

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.

UpgradesHigh3/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

27.2% in top 10
7.2% in wallets20.0% in contracts
Effective Concentration15.2%

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

$127.2K across 6 pairs
Pancakeswap v2SPCXBanalysed$122.3K96.2%Pancakeswap v3USDT$4.9K3.8%Pancakeswap v2WBNB$160.0%Uniswap v2USDT$10.0%Uniswap v2WBNB$00.0%

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

Top-1 Unlocked Holder39.9%
Top-3 Unlocked85.8%

Key Addresses

11 addresses
Deployer
0x1a11…66f4
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.

What Raised This Score

9 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

Related Audits

6 more on the record
GoPlus Security (GPS)High RiskPro Token (PRO)High RiskXPULSHigh RiskHana Token (HANA)High RiskElonCoinHigh RiskUpstarty (UPY)High Risk

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