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 →

全新托底+销毁分红+强大生态 招财猫
0x59cd…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 7d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and multiple pool states. The audit identified a potential critical reentrancy vulnerability within the `_liquidateTax` function, which is called on every transfer, due to incomplete code. Other findings include centralized owner control, reliance on `block.timestamp` for critical state transitions, and potential issues with unhandled external contract failures. The contract utilizes OpenZeppelin's upgradeable standards, which is a strong foundation, but the custom logic introduces specific risks.

1 Critical2 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
$803.7K
Liquidity
$217.3K
Price
$0.005048
Token Age
1d
Top 10 Holders
93.8%

Security Findings

1 Crit2 Med1 Low1 Info
Critical

Reentrancy Risk in `_liquidateTax` (Incomplete Logic)

C-01The `_liquidateTax` function is called on every `_transfer` and is responsible for handling accumulated tax tokens. While the provided code is truncated, the function's name and the presence of `taxProcessor` and `dividendContract` strongly suggest it performs external token transfers to these addresses. If these external calls are made before updating the contract's internal state (e.g., zeroing out the accumulated tax balance or setting a reentrancy guard), a malicious `taxProcessor` or `dividendContract` (or a contract that receives tokens from them) could re-enter the `_transfer` function. This could lead to multiple liquidations from a single transfer, potentially draining the contract…
IssueThe `_liquidateTax` function is called on every `_transfer` and is responsible for handling accumulated tax tokens. While the provided code is truncated, the function's name and the presence of `taxProcessor` and `dividendContract` strongly suggest it performs external token transfers to these addresses. If these external calls are made before updating the contract's internal state (e.g., zeroing out the accumulated tax balance or setting a reentrancy guard), a malicious `taxProcessor` or `dividendContract` (or a contract that receives tokens from them) could re-enter the `_transfer` function. This could lead to multiple liquidations from a single transfer, potentially draining the contract…
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on `_liquidateTax` or ensure that all state updates related to tax liquidation are completed *before* any external calls are made. Additionally, consider using a 'checks-effects-interactions' pattern. A full review of the complete `_liquidateTax` logic is required to confirm and mitigate this risk.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The `onlyOwner` modifier grants significant control over critical functions such as `startMigration` and `finalizeMigration`, which directly change the `PoolState` and affect tax enforcement. While common for initial contract phases, this centralizes power and introduces a single point of failure or attack vector if the owner's private key is compromised. This level of control could also be a governance risk in the long term.
IssueThe `onlyOwner` modifier grants significant control over critical functions such as `startMigration` and `finalizeMigration`, which directly change the `PoolState` and affect tax enforcement. While common for initial contract phases, this centralizes power and introduces a single point of failure or attack vector if the owner's private key is compromised. This level of control could also be a governance risk in the long term.
FixConsider implementing a multi-signature wallet for ownership or transitioning to a more decentralized governance model as the protocol matures. If a single owner remains, ensure robust security practices for the owner's private key.
StatusUnresolved
Medium

Reliance on `block.timestamp` for Critical State Transitions

M-02The `_liquidateTax` function uses `block.timestamp` to determine `taxExpirationTime` and `antiFarmerExpirationTime`, which trigger changes in the `PoolState` (e.g., to `TaxFree` or `TaxEnforced`). While `block.timestamp` is generally suitable for expiration checks, miners can manipulate it within a certain range (e.g., up to 900 seconds on Ethereum, similar on BSC). This could allow a miner to prematurely trigger or delay state transitions, potentially affecting tax collection or anti-farmer mechanisms.
IssueThe `_liquidateTax` function uses `block.timestamp` to determine `taxExpirationTime` and `antiFarmerExpirationTime`, which trigger changes in the `PoolState` (e.g., to `TaxFree` or `TaxEnforced`). While `block.timestamp` is generally suitable for expiration checks, miners can manipulate it within a certain range (e.g., up to 900 seconds on Ethereum, similar on BSC). This could allow a miner to prematurely trigger or delay state transitions, potentially affecting tax collection or anti-farmer mechanisms.
FixFor time-sensitive operations where miner manipulation could have significant economic impact, consider using `block.number` in conjunction with an average block time, or an oracle for time if higher precision and resistance to manipulation are required. For simple expiration checks, `block.timestamp` is often acceptable, but the impact of potential manipulation should be thoroughly assessed.
StatusUnresolved
Low

Unhandled External Contract Failures in `_liquidateTax`

L-01The truncated `_liquidateTax` function likely interacts with `ITaxProcessor` and `IDividend` for distributing accumulated tax. If these external calls revert or fail silently (e.g., due to gas limits, unexpected logic in the external contract, or reentrancy guards in the recipient), the `_liquidateTax` function might not complete its intended operations. This could leave accumulated tax funds stuck in the contract or lead to an inconsistent state regarding tax distribution, even though `SafeERC20` is used for token transfers.
IssueThe truncated `_liquidateTax` function likely interacts with `ITaxProcessor` and `IDividend` for distributing accumulated tax. If these external calls revert or fail silently (e.g., due to gas limits, unexpected logic in the external contract, or reentrancy guards in the recipient), the `_liquidateTax` function might not complete its intended operations. This could leave accumulated tax funds stuck in the contract or lead to an inconsistent state regarding tax distribution, even though `SafeERC20` is used for token transfers.
FixImplement explicit error handling for external calls within `_liquidateTax` using `try/catch` blocks. This allows the contract to gracefully handle failures, log events, or revert the transaction if the tax distribution is critical for state consistency. Ensure sufficient gas is forwarded for external calls.
StatusUnresolved
Info

Potential Gas Limit Issues for `_transfer`

I-01The `_liquidateTax` function is called on every `_transfer` and involves multiple state updates and potentially external calls (to `taxProcessor` and `dividendContract`). If the liquidation logic is complex or involves many operations, there's a risk that a `_transfer` operation could exceed the block gas limit under certain conditions, especially if the accumulated `taxAmount` is large and requires many operations for distribution. This could lead to failed transactions for users.
IssueThe `_liquidateTax` function is called on every `_transfer` and involves multiple state updates and potentially external calls (to `taxProcessor` and `dividendContract`). If the liquidation logic is complex or involves many operations, there's a risk that a `_transfer` operation could exceed the block gas limit under certain conditions, especially if the accumulated `taxAmount` is large and requires many operations for distribution. This could lead to failed transactions for users.
FixMonitor gas usage of `_transfer` and `_liquidateTax` functions under various scenarios, especially with large tax amounts and multiple external recipients. Optimize the liquidation logic to minimize gas consumption. Consider implementing a separate, owner-triggered function for liquidation if the complexity or gas cost becomes prohibitive for regular transfers, or batching liquidation operations.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's upgradeable ERC20 and access control modules, providing a robust and well-tested foundation (7.2 Code Security). State management through the `PoolState` enum and `PackedPoolState` struct is well-structured, enhancing clarity and gas efficiency (7.1 Architecture). However, a significant concern is the potential for reentrancy within the `_liquidateTax` function, which is called on every transfer and likely involves external calls to `taxProcessor` and `dividendContract` (7.2 Code Security, 7.6 External). This could lead to unintended fund drains or state manipulation if not properly guarded. Additionally, the reliance on `block.timestamp` for critical state transitions introduces a minor risk of miner manipulation (7.2 Code Security).

GovernanceMedium4/10

The contract's economic model includes dynamic buy/sell taxes and multiple pool states (7.4 Economic), which are clearly defined and managed. Critical state transitions, such as `startMigration` and `finalizeMigration`, are appropriately restricted to the contract owner (7.3 Access Control, 7.5 Governance). This centralized control, while common, means the owner's private key is a single point of failure (7.3 Access Control). The use of `block.timestamp` for tax and anti-farmer expiration times introduces a minor risk of manipulation by miners, potentially affecting the intended economic flow (7.4 Economic).

UpgradesLow8/10

The contract is designed as an upgradeable proxy, correctly inheriting from `Initializable` and using OpenZeppelin's upgradeable contracts (7.7 Upgrades). The constructor correctly calls `_disableInitializers()` to prevent re-initialization of the implementation contract. The `initialize` function is properly guarded with the `initializer` modifier. While the `PackedPoolState` struct is used, future upgrades must carefully manage storage layout to avoid collisions, a standard consideration for upgradeable contracts (7.7 Upgrades).

Security Checklist

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

Holder Composition

93.8% in top 10
90.7% in wallets3.1% in contracts
Effective Concentration91.9%

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

$217.3K

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0xfc74…2846

What Raised This Score

5 factors
  • Top-10 concentration > 70% (93.8% total → 91.9% effective; 90.7% in EOAs, 3.1% in contracts — extreme)
  • Token age < 7 days (early, volatile)
  • 1 Critical 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
Non-Playable Coin (NPC)Medium RiskMubarakahMedium RiskCets On Gold (CETS)Medium Risk孙小圣Medium RiskMOMOMedium RiskAltura (ALU)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