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 →

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

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex, multi-state tax mechanism. The audit identified a critical reentrancy vulnerability in the `_liquidateTax` function, which performs external calls after modifying internal state but before fully processing the liquidation. Additionally, a critical section of the `_liquidateTax` function was truncated in the provided source code, preventing a complete security analysis of its logic. The contract also exhibits high complexity in its state machine and relies on owner-controlled functions for critical transitions.

1 Critical1 High3 Medium1 Low
! Early-stage analysis. This token has limited on-chain history (5d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.27M
Liquidity
$128.0K
Price
$0.001023
Token Age
5d
Top 10 Holders
16.9%

Security Findings

1 Crit1 High3 Med1 Low
Critical

Reentrancy Vulnerability in `_liquidateTax`

C-01The `_liquidateTax` function, called during every `_transfer`, performs external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividend`. These external calls occur after internal state variables (e.g., `poolState`) may have been updated but before the full liquidation process is complete or a reentrancy guard is applied. A malicious `taxProcessor` or `dividendContract` could re-enter the token contract, potentially manipulating balances, triggering unintended state transitions, or causing double-spending of tax amounts before the current transaction is finalized.
IssueThe `_liquidateTax` function, called during every `_transfer`, performs external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividend`. These external calls occur after internal state variables (e.g., `poolState`) may have been updated but before the full liquidation process is complete or a reentrancy guard is applied. A malicious `taxProcessor` or `dividendContract` could re-enter the token contract, potentially manipulating balances, triggering unintended state transitions, or causing double-spending of tax amounts before the current transaction is finalized.
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on the `_liquidateTax` function or strictly follow the Checks-Effects-Interactions pattern. Ensure that all state changes related to tax liquidation are finalized before any external calls are made. Consider setting a `notLiquidating` flag to `false` at the beginning of the function and resetting it only after all external calls and state updates are complete.
StatusUnresolved
High

Complex State Machine and Potential for Misconfiguration

H-01The contract implements a highly complex state machine with multiple `PoolState` transitions (`BondingCurve`, `Migrating`, `TaxEnforcedAntiFarmer`, `TaxEnforced`, `TaxFree`) and intricate tax calculation logic (`_getTaxWithPoolState`). State changes can occur automatically based on `block.timestamp` in `_liquidateTax` or manually via `onlyOwner` functions. This complexity increases the risk of logical errors, unintended state transitions, or misconfigurations of initial parameters (`taxDuration`, `antiFarmerDuration`, `mainPool`), which could lead to incorrect tax application or economic instability.
IssueThe contract implements a highly complex state machine with multiple `PoolState` transitions (`BondingCurve`, `Migrating`, `TaxEnforcedAntiFarmer`, `TaxEnforced`, `TaxFree`) and intricate tax calculation logic (`_getTaxWithPoolState`). State changes can occur automatically based on `block.timestamp` in `_liquidateTax` or manually via `onlyOwner` functions. This complexity increases the risk of logical errors, unintended state transitions, or misconfigurations of initial parameters (`taxDuration`, `antiFarmerDuration`, `mainPool`), which could lead to incorrect tax application or economic instability.
FixThoroughly document all possible state transitions, their triggers, and expected outcomes. Conduct extensive unit and integration testing covering all edge cases and parameter combinations. Consider simplifying the state machine if possible, or adding robust invariant checks to ensure the system remains in a valid state.
StatusUnresolved
Medium

Truncated Code Prevents Full Audit

M-01A critical section of the `_liquidateTax` function was truncated in the provided source code: `taxAmount >= currentPoolState.liqu... (truncated)`. This prevents a complete and accurate security analysis of the tax liquidation conditions and logic, which is central to the contract's economic model. The missing code could contain additional vulnerabilities, logical flaws, or critical operational details.
IssueA critical section of the `_liquidateTax` function was truncated in the provided source code: `taxAmount >= currentPoolState.liqu... (truncated)`. This prevents a complete and accurate security analysis of the tax liquidation conditions and logic, which is central to the contract's economic model. The missing code could contain additional vulnerabilities, logical flaws, or critical operational details.
FixProvide the complete and untruncated source code for the `FlapTaxTokenV3` contract, specifically the `_liquidateTax` function, to enable a comprehensive security assessment.
StatusUnresolved
Medium

Reliance on External Contracts for Critical Operations

M-02The contract relies on external addresses, `taxProcessor` and `dividendContract`, for core functionalities such as processing collected taxes and distributing dividends. These addresses are set during initialization and are critical to the token's economic model. If these external contracts are malicious, become compromised, are paused, or are upgraded incorrectly, they could disrupt the token's tax mechanism, prevent dividend distribution, or lead to loss of funds.
IssueThe contract relies on external addresses, `taxProcessor` and `dividendContract`, for core functionalities such as processing collected taxes and distributing dividends. These addresses are set during initialization and are critical to the token's economic model. If these external contracts are malicious, become compromised, are paused, or are upgraded incorrectly, they could disrupt the token's tax mechanism, prevent dividend distribution, or lead to loss of funds.
FixEnsure that `taxProcessor` and `dividendContract` are thoroughly audited, robust, and have appropriate access controls. Implement mechanisms to pause or replace these external contracts in an emergency, possibly with a time-locked or multi-signature controlled setter function. Clearly document the expected behavior and security properties of these external dependencies.
StatusUnresolved
Medium

Centralization Risk with Owner-Controlled Functions

M-03The `startMigration` and `finalizeMigration` functions, which control critical `PoolState` transitions, are protected by the `onlyOwner` modifier. This grants significant power to a single address to unilaterally change the contract's operational state. While common for initial setup, a compromised owner key or a malicious owner could manipulate the token's behavior, potentially impacting users or the economic model.
IssueThe `startMigration` and `finalizeMigration` functions, which control critical `PoolState` transitions, are protected by the `onlyOwner` modifier. This grants significant power to a single address to unilaterally change the contract's operational state. While common for initial setup, a compromised owner key or a malicious owner could manipulate the token's behavior, potentially impacting users or the economic model.
FixConsider migrating ownership of critical functions to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and reduce the risk of a single point of failure. For highly sensitive operations, implement a time-lock mechanism to allow community review or provide a window for users to react before changes take effect.
StatusUnresolved
Low

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

L-01The `_liquidateTax` function uses `block.timestamp` to check `taxExpirationTime` and `antiFarmerExpirationTime` for automatic state transitions. Miners have a limited ability to manipulate `block.timestamp` (typically within a 15-second window on Ethereum, but can vary on other chains like BSC). This could allow for minor front-running opportunities to slightly delay or accelerate state changes, potentially affecting tax rates or liquidation timing for specific transactions.
IssueThe `_liquidateTax` function uses `block.timestamp` to check `taxExpirationTime` and `antiFarmerExpirationTime` for automatic state transitions. Miners have a limited ability to manipulate `block.timestamp` (typically within a 15-second window on Ethereum, but can vary on other chains like BSC). This could allow for minor front-running opportunities to slightly delay or accelerate state changes, potentially affecting tax rates or liquidation timing for specific transactions.
FixBe aware of the inherent limitations and potential for manipulation when using `block.timestamp` for precise timing. For critical time-sensitive operations where even minor manipulation is unacceptable, consider using a decentralized oracle for time or a more robust timing mechanism. For the current use case, the impact is likely low, but it's important to acknowledge the risk.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable standards for ERC20, Ownable, and Permit, demonstrating sound architectural choices (7.1 Architecture). The use of `PackedPoolState` is an efficient gas-saving technique. However, a critical reentrancy vulnerability exists in the `_liquidateTax` function due to external calls to `ITaxProcessor` and `IDividend` before state updates are fully finalized (7.2 Code Security). The complex state machine and intricate tax logic also introduce significant technical complexity and potential for unintended behavior (7.2 Code Security).

GovernanceMedium6/10

The economic model is built around a dynamic tax mechanism that adjusts based on `PoolState` and time-based expirations, influencing token transfers (7.4 Economic). Critical state transitions, such as `startMigration` and `finalizeMigration`, are controlled by `onlyOwner` functions, introducing a centralization risk (7.3 Access Control, 7.5 Governance). Furthermore, the contract's core tax processing and dividend distribution rely on external `taxProcessor` and `dividendContract` addresses, creating dependencies (7.6 External).

UpgradesLow8/10

The contract is implemented as an upgradeable proxy using OpenZeppelin's `Initializable` and `ERC20Upgradeable` patterns, which is a well-established and secure approach for upgradeability (7.7 Upgrades). The constructor correctly disables initializers, and the `initialize` function is protected by the `initializer` modifier, preventing re-initialization.

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

16.9% in top 10
6.0% in wallets10.9% in contracts
Effective Concentration10.4%

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

$144.6K across 7 pairs
Pancakeswap v2GOOGLBanalysed$128.0K88.5%Pancakeswap v3USDT$16.5K11.4%Uniswap v2USDC$260.0%Pancakeswap v2WBNB$240.0%Uniswap v2USDT$40.0%Pancakeswap v2USDT$10.0%
Show 1 more pairShow less
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 Holder11.2%
Top-3 Unlocked28.8%

Key Addresses

11 addresses
Deployer
0xde07…b710
Unlocked LP Held By
0xf92f…4a700x3f35…9e860x8e0b…e8380x9e96…16a20x8b42…cc3f0x6825…c4c30x8ca3…8b880x9277…7f5d0xee04…67730x8c2b…3a89

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

What Raised This Score

6 factors
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 3 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
Bitway Token (BTW)Medium RiskMarsCoinMedium RiskCZ'S DOG (BROCCOLI)Medium RiskCharacterX (CAI)Medium RiskFetch (FET)Medium RiskMame Inu (MAME)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