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 →

永生果蝇 永生果蝇
0x225a…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 3d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers the FlapTaxTokenV3 contract, an upgradeable ERC20 token with a dynamic tax mechanism. A critical portion of the `_liquidateTax` function was truncated in the provided source, preventing a comprehensive security assessment of the core tax collection and distribution logic. This significantly limits the scope and confidence of the audit, leading to a Critical overall risk level due to unverified core functionality.

1 Critical1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$738.2K
Liquidity
$75.5K
Price
$0.0005391
Token Age
1d
Top 10 Holders
29.0%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Incomplete `_liquidateTax` Function Prevents Full Audit

C-01The provided source code for the `_liquidateTax` function is truncated. This function is called on every `_transfer` to the `mainPool` and is responsible for handling collected taxes, managing state transitions based on `taxExpirationTime` and `antiFarmerExpirationTime`, and potentially interacting with `taxProcessor` or `dividendContract`. Without the complete code, it is impossible to assess critical aspects such as reentrancy vulnerabilities, correct tax distribution logic, potential for fund locking, or proper handling of external calls. This severely limits the scope and confidence of the entire audit (7.2 Code Security, 7.4 Economic).
IssueThe provided source code for the `_liquidateTax` function is truncated. This function is called on every `_transfer` to the `mainPool` and is responsible for handling collected taxes, managing state transitions based on `taxExpirationTime` and `antiFarmerExpirationTime`, and potentially interacting with `taxProcessor` or `dividendContract`. Without the complete code, it is impossible to assess critical aspects such as reentrancy vulnerabilities, correct tax distribution logic, potential for fund locking, or proper handling of external calls. This severely limits the scope and confidence of the entire audit (7.2 Code Security, 7.4 Economic).
FixProvide the complete and untruncated source code for the `_liquidateTax` function to allow for a comprehensive security review of this critical component. A full audit cannot be completed without this information.
StatusUnresolved
High

Centralized Control via `onlyOwner`

H-01The `onlyOwner` modifier grants significant control over critical contract functions, including `startMigration` and `finalizeMigration`. This centralization of power means that a single compromised private key or a malicious owner could unilaterally alter the contract's operational state, potentially impacting token transfers, tax rates, and overall protocol stability. This introduces a single point of failure (7.3 Access Control, 7.5 Governance).
IssueThe `onlyOwner` modifier grants significant control over critical contract functions, including `startMigration` and `finalizeMigration`. This centralization of power means that a single compromised private key or a malicious owner could unilaterally alter the contract's operational state, potentially impacting token transfers, tax rates, and overall protocol stability. This introduces a single point of failure (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet for the owner role to distribute control and reduce the risk associated with a single point of failure. For highly sensitive operations, a time-locked governance mechanism could be explored to provide transparency and allow users to react to proposed changes.
StatusUnresolved
Medium

Potential for Tax Accumulation Without Liquidation

M-01The `_liquidateTax` function, which is responsible for processing collected taxes, is only triggered when a transfer's `to` address is the `mainPool`. If transfers to the `mainPool` are infrequent or cease, collected tax amounts held by the contract (`balanceOf(address(this))`) could accumulate indefinitely without being processed or distributed. This could lead to locked funds or delayed dividend payouts, impacting the economic model (7.4 Economic, 7.8 Operations).
IssueThe `_liquidateTax` function, which is responsible for processing collected taxes, is only triggered when a transfer's `to` address is the `mainPool`. If transfers to the `mainPool` are infrequent or cease, collected tax amounts held by the contract (`balanceOf(address(this))`) could accumulate indefinitely without being processed or distributed. This could lead to locked funds or delayed dividend payouts, impacting the economic model (7.4 Economic, 7.8 Operations).
FixImplement a mechanism to allow the owner or a designated role to manually trigger tax liquidation, or introduce a time-based fallback to process accumulated taxes if the `mainPool` condition is not met within a certain period. This ensures that collected taxes are always processed, regardless of transfer patterns.
StatusUnresolved
Low

Hardcoded `maxSupply` and Initial Mint to Deployer

L-01The `maxSupply` of 1 billion tokens is hardcoded and all tokens are minted to `msg.sender` (the deployer) during the `initialize` function. This design centralizes the entire token supply in a single address at deployment, which could raise concerns regarding token distribution, market manipulation, or potential for a large single point of failure if the deployer's wallet is compromised (7.4 Economic).
IssueThe `maxSupply` of 1 billion tokens is hardcoded and all tokens are minted to `msg.sender` (the deployer) during the `initialize` function. This design centralizes the entire token supply in a single address at deployment, which could raise concerns regarding token distribution, market manipulation, or potential for a large single point of failure if the deployer's wallet is compromised (7.4 Economic).
FixWhile this might be an intentional design choice for specific tokenomics, consider documenting the distribution plan for the initial supply. For future projects, explore more decentralized initial distribution mechanisms or vesting schedules if broader community ownership is desired.
StatusUnresolved
Info

Reliance on `block.timestamp` for Time-Sensitive Logic

I-01The contract uses `block.timestamp` for time-sensitive logic, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While common, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum, similar on BSC), potentially allowing them to slightly front-run or back-run state transitions if they have an economic incentive (7.2 Code Security).
IssueThe contract uses `block.timestamp` for time-sensitive logic, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While common, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum, similar on BSC), potentially allowing them to slightly front-run or back-run state transitions if they have an economic incentive (7.2 Code Security).
FixFor most applications, `block.timestamp` is sufficient. However, for highly critical time-sensitive operations where even minor manipulation could lead to significant economic advantage, consider using Chainlink Keepers or similar decentralized oracle networks for time-based triggers, or implement a time-weighted average of block timestamps if extreme precision and resistance to miner manipulation are paramount.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable standards for ERC20, Ownable, and Permit functionalities, demonstrating good practice in modularity and security patterns (7.1 Architecture, 7.2 Code Security). The use of `SafeERC20` for token interactions enhances security against reentrancy. However, a critical section of the `_liquidateTax` function was truncated, making it impossible to fully assess the security of the tax processing and distribution logic (7.2 Code Security). This unverified component represents a significant technical risk.

GovernanceMedium4/10

The contract implements a dynamic tax system with various `PoolState`s and time-based transitions, managed by the owner (7.4 Economic, 7.5 Governance). The `onlyOwner` modifier grants the deployer significant control over critical state changes like migration, posing a centralization risk (7.3 Access Control). The initial mint of all `maxSupply` to the deployer also centralizes token distribution (7.4 Economic). The economic implications of the tax mechanism, particularly its liquidation and distribution, cannot be fully assessed due to missing code (7.4 Economic).

UpgradesLow8/10

The contract utilizes the UUPS proxy pattern via OpenZeppelin's `Initializable` and `Upgradeable` contracts, providing a robust and well-understood upgrade mechanism (7.7 Upgrades). The constructor correctly calls `_disableInitializers()` to prevent re-initialization of the implementation contract. However, the `onlyOwner` role has the authority to initiate and finalize migrations, which implies control over potential upgrade-related state changes, centralizing upgrade management (7.7 Upgrades, 7.3 Access Control).

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

29.0% in top 10
18.5% in wallets10.5% in contracts
Effective Concentration22.7%

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

$75.6K across 5 pairs
Pancakeswap v2AAPLBanalysed$75.5K100.0%Pancakeswap v3USDT$220.0%Pancakeswap v2flap多托底协议$50.0%Pancakeswap v2多托底$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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x42ab…3c4e
Unlocked LP Held By
0x02fe…9283

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

What Raised This Score

9 factors
  • Top-10 concentration > 20% (29.0% total → 22.7% effective; 18.5% in EOAs, 10.5% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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
CookieHigh RiskCrossHigh RiskChainOpera AI (COAI)High RiskYooldo Games (ESPORTS)High RiskAKEHigh RiskVelvetHigh 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