Quantum Audit Logo

Is 中国人能飞火箭 a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

中国人能飞火箭 中国人能飞
0x1088…7777
BNB Chain
Not verifiedThis 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 today 1 audit on record New Launch · 6d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of FlapTaxTokenV3, an upgradeable ERC20 token with a complex multi-state tax mechanism, was conducted. A significant portion of the critical `_liquidateTax` function was truncated, preventing a full assessment of its security and economic implications. Key findings include high centralization risks due to the owner controlling the entire initial token supply and critical state transitions, alongside potential reentrancy vulnerabilities in the incomplete liquidation logic. The contract utilizes standard OpenZeppelin upgradeable patterns, which appear correctly implemented.

2 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (6d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$469.9K
Liquidity
$94.4K
Price
$0.0006463
Token Age
6d
Top 10 Holders
18.9%

Security Findings

2 High2 Med1 Low1 Info
High

Truncated Critical Liquidation Logic

H-01The `_liquidateTax` function, which is called on every `_transfer` and is central to the token's economic model and state transitions, is significantly truncated in the provided source code. This prevents a full security assessment of potential reentrancy vulnerabilities, external call risks, gas consumption, and the overall economic stability and fairness of the tax and liquidation mechanism (7.2 Code Security, 7.4 Economic).
IssueThe `_liquidateTax` function, which is called on every `_transfer` and is central to the token's economic model and state transitions, is significantly truncated in the provided source code. This prevents a full security assessment of potential reentrancy vulnerabilities, external call risks, gas consumption, and the overall economic stability and fairness of the tax and liquidation mechanism (7.2 Code Security, 7.4 Economic).
FixProvide the complete and verified source code for the `_liquidateTax` function to allow for a comprehensive security audit. Without the full implementation, critical vulnerabilities may remain undetected.
StatusUnresolved
High

Centralized Control of Initial Token Supply

H-02The `initialize` function mints the entire `maxSupply` (1 billion tokens) directly to the contract deployer (`msg.sender`), who is also the owner. This grants the owner complete control over the initial token distribution, posing a significant centralization risk and potential for market manipulation or unfair distribution (7.4 Economic, 7.5 Governance).
IssueThe `initialize` function mints the entire `maxSupply` (1 billion tokens) directly to the contract deployer (`msg.sender`), who is also the owner. This grants the owner complete control over the initial token distribution, posing a significant centralization risk and potential for market manipulation or unfair distribution (7.4 Economic, 7.5 Governance).
FixConsider a more decentralized or transparent mechanism for initial token distribution, such as a vesting schedule, a public sale, or a multi-signature wallet for managing the initial supply. This reduces the single point of failure and increases trust.
StatusUnresolved
Medium

Potential Reentrancy in `_liquidateTax` (Due to Truncation)

M-01The `_liquidateTax` function is called on every `_transfer` and is likely to contain external calls (e.g., to `taxProcessor`, `dividendContract`, or `v2Router` for swaps) in its truncated part. If these external calls are made before critical state updates or without proper reentrancy guards (like OpenZeppelin's `nonReentrant` modifier), the contract could be vulnerable to reentrancy attacks (7.2 Code Security).
IssueThe `_liquidateTax` function is called on every `_transfer` and is likely to contain external calls (e.g., to `taxProcessor`, `dividendContract`, or `v2Router` for swaps) in its truncated part. If these external calls are made before critical state updates or without proper reentrancy guards (like OpenZeppelin's `nonReentrant` modifier), the contract could be vulnerable to reentrancy attacks (7.2 Code Security).
FixUpon providing the full `_liquidateTax` source code, ensure that all external calls adhere to the Checks-Effects-Interactions pattern. Implement reentrancy guards (e.g., `nonReentrant` from OpenZeppelin) on functions that make external calls and modify critical state, especially if they are called within the `_transfer` flow.
StatusUnresolved
Medium

Critical Owner Privileges

M-02The `onlyOwner` role has significant control over critical state transitions, specifically `startMigration` and `finalizeMigration`, which directly impact the token's operational state and tax enforcement. This centralization introduces a single point of failure, where a compromised owner key could lead to unauthorized state changes or manipulation of the token's tax mechanics (7.3 Access Control, 7.5 Governance).
IssueThe `onlyOwner` role has significant control over critical state transitions, specifically `startMigration` and `finalizeMigration`, which directly impact the token's operational state and tax enforcement. This centralization introduces a single point of failure, where a compromised owner key could lead to unauthorized state changes or manipulation of the token's tax mechanics (7.3 Access Control, 7.5 Governance).
FixImplement a multi-signature wallet for the owner address to enhance security. Consider introducing a time-lock for critical owner-controlled operations to provide a window for community review or intervention. Explore mechanisms for progressive decentralization of these controls over time.
StatusUnresolved
Low

Complex Multi-State Tax Machine

L-01The contract implements a complex multi-state tax system (`BondingCurve`, `Migrating`, `TaxEnforcedAntiFarmer`, `TaxEnforced`, `TaxFree`) with various conditions for state transitions and tax application. While designed for specific tokenomics, this complexity increases the surface area for logical errors and makes auditing, understanding, and maintaining the contract more challenging (7.1 Architecture, 7.2 Code Security).
IssueThe contract implements a complex multi-state tax system (`BondingCurve`, `Migrating`, `TaxEnforcedAntiFarmer`, `TaxEnforced`, `TaxFree`) with various conditions for state transitions and tax application. While designed for specific tokenomics, this complexity increases the surface area for logical errors and makes auditing, understanding, and maintaining the contract more challenging (7.1 Architecture, 7.2 Code Security).
FixEnsure comprehensive unit and integration tests cover all possible state transitions and tax calculation scenarios. Provide detailed documentation and flowcharts explaining the state machine logic and its intended behavior to minimize misinterpretations and potential errors.
StatusUnresolved
Info

Reliance on `block.timestamp` for Expiration

I-01The `taxExpirationTime` and `antiFarmerExpirationTime` variables rely on `block.timestamp` for their calculation and comparison. While common, `block.timestamp` can be manipulated by miners within a small range (up to 900 seconds on Ethereum, similar on BSC), which could slightly influence the precise timing of state transitions (7.2 Code Security).
IssueThe `taxExpirationTime` and `antiFarmerExpirationTime` variables rely on `block.timestamp` for their calculation and comparison. While common, `block.timestamp` can be manipulated by miners within a small range (up to 900 seconds on Ethereum, similar on BSC), which could slightly influence the precise timing of state transitions (7.2 Code Security).
FixFor time-sensitive operations, consider using `block.number` and average block times if precise, unmanipulable timing is critical. However, for expiration times of this nature, `block.timestamp` is generally considered acceptable, and the risk is low.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract implements a multi-state tax system and overrides the `_transfer` function to apply custom logic, including calling `_liquidateTax`. The use of `PackedPoolState` is a gas-efficient design choice. However, the truncation of the `_liquidateTax` function (7.2 Code Security) prevents a complete analysis of potential reentrancy vulnerabilities and gas consumption issues. The reliance on `block.timestamp` for expiration (7.2 Code Security) introduces minor miner manipulability.

GovernanceMedium4/10

The economic model is centered around a dynamic tax system and a liquidation mechanism. A major concern is the initial minting of the entire `maxSupply` to the deployer (7.4 Economic), granting the owner immense control over the token's distribution and market. The owner also holds critical privileges for state transitions (7.3 Access Control, 7.5 Governance), introducing a single point of failure. The full economic implications of the liquidation process cannot be assessed due to truncated code (7.4 Economic).

UpgradesLow8/10

The contract correctly utilizes OpenZeppelin's `Initializable` and `__Ownable_init` patterns for upgradeability (7.7 Upgrades). The constructor disables initializers, preventing re-initialization attacks. This standard UUPS proxy implementation appears robust, allowing for future logic upgrades while maintaining state.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

18.9% in top 10
6.5% in wallets12.4% in contracts
Effective Concentration11.5%

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

$97.0K across 2 pairs
Pancakeswap v2FXIonanalysed$94.4K97.3%Pancakeswap v3USDT$2.7K2.7%

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.

Key Addresses

1 addresses
Deployer
0xae9b…54b0

What Raised This Score

5 factors
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Token age < 7 days (early, volatile)
  • 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
Mame Inu (MAME)Medium RiskOLAXBT (AIO)Medium RiskLUNAMedium RiskBitway Token (BTW)Medium RiskMarsCoinMedium RiskCZ'S DOG (BROCCOLI)Medium Risk

Would You Like a More Detailed Audit of 中国人能飞火箭?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit