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 →

牛梦 牛梦
0xee22…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 9d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and anti-farmer features. While it utilizes OpenZeppelin's battle-tested upgradeable components, a critical vulnerability exists due to truncated code in the `_liquidateTax` function, preventing a full security assessment of core logic. High-severity issues include centralized control over critical state transitions and potential for manipulation/high gas costs within the `_liquidateTax` function. Medium-severity findings relate to inflexible pool management and a long-term integer overflow risk. Addressing the truncated code is paramount for the security of the protocol.

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

Security Findings

1 Crit2 High2 Med1 Low1 Info
Critical

Truncated `_liquidateTax` Function Logic

C-01The provided source code for the `_liquidateTax` function is truncated, specifically the part dealing with the actual liquidation of `taxAmount`. This function is called on every `_transfer` operation. Without the complete logic, it is impossible to assess critical security aspects such as reentrancy risks, external call vulnerabilities, potential for denial-of-service, or incorrect handling of funds. This represents a severe unknown risk (7.2 Code Security, 7.6 External).
IssueThe provided source code for the `_liquidateTax` function is truncated, specifically the part dealing with the actual liquidation of `taxAmount`. This function is called on every `_transfer` operation. Without the complete logic, it is impossible to assess critical security aspects such as reentrancy risks, external call vulnerabilities, potential for denial-of-service, or incorrect handling of funds. This represents a severe unknown risk (7.2 Code Security, 7.6 External).
FixProvide the complete and verified source code for the `_liquidateTax` function to allow for a thorough security review.
StatusUnresolved
High

Centralized Control over Core Token State Transitions

H-01The `startMigration` and `finalizeMigration` functions, which control the critical `PoolState` transitions (e.g., from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`), are protected by the `onlyOwner` modifier. This grants the contract owner unilateral power to enable or disable core token functionalities like tax enforcement and anti-farmer mechanisms, significantly impacting the token's economic model and user experience (7.3 Access Control, 7.5 Governance).
IssueThe `startMigration` and `finalizeMigration` functions, which control the critical `PoolState` transitions (e.g., from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`), are protected by the `onlyOwner` modifier. This grants the contract owner unilateral power to enable or disable core token functionalities like tax enforcement and anti-farmer mechanisms, significantly impacting the token's economic model and user experience (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet for owner functions or introducing a time-lock mechanism for critical state changes to reduce single-point-of-failure risk and provide transparency.
StatusUnresolved
High

Potential for Manipulation and High Gas Costs in `_liquidateTax`

H-02The `_liquidateTax` function is invoked on every `_transfer` call. This function performs time-based state transitions (`taxExpirationTime`, `antiFarmerExpirationTime`) and checks `balanceOf(address(this))` to trigger liquidation. Miners can slightly influence `block.timestamp`, potentially front-running or delaying state transitions. Additionally, if the contract's balance can be manipulated by external transfers, it could affect the `taxAmount > 0` condition, potentially preventing or forcing liquidations. Calling this function on every transfer, especially if the truncated liquidation logic involves complex calculations or external calls, could lead to unexpectedly high gas costs for use…
IssueThe `_liquidateTax` function is invoked on every `_transfer` call. This function performs time-based state transitions (`taxExpirationTime`, `antiFarmerExpirationTime`) and checks `balanceOf(address(this))` to trigger liquidation. Miners can slightly influence `block.timestamp`, potentially front-running or delaying state transitions. Additionally, if the contract's balance can be manipulated by external transfers, it could affect the `taxAmount > 0` condition, potentially preventing or forcing liquidations. Calling this function on every transfer, especially if the truncated liquidation logic involves complex calculations or external calls, could lead to unexpectedly high gas costs for use…
FixRe-evaluate the necessity of calling `_liquidateTax` on every transfer. Consider a dedicated, permissioned function for liquidation or a more gas-efficient trigger. Ensure the full liquidation logic is robust against reentrancy and external call failures. Implement safeguards against balance manipulation affecting liquidation triggers.
StatusUnresolved
Medium

Inflexible Pool Management

M-01The `pools` mapping and `mainPool` address are initialized only once during the `initialize` function. There are no owner-controlled or governance-controlled functions to add, remove, or modify these pool addresses after deployment. This inflexibility means that if a pool address changes, a new pool needs to be added, or the `mainPool` needs to be updated, a contract upgrade would be required (7.1 Architecture, 7.8 Operations).
IssueThe `pools` mapping and `mainPool` address are initialized only once during the `initialize` function. There are no owner-controlled or governance-controlled functions to add, remove, or modify these pool addresses after deployment. This inflexibility means that if a pool address changes, a new pool needs to be added, or the `mainPool` needs to be updated, a contract upgrade would be required (7.1 Architecture, 7.8 Operations).
FixImplement owner-controlled functions (e.g., `addPool(address _pool)`, `removePool(address _pool)`, `setMainPool(address _mainPool)`) to allow for flexible management of pool addresses. Consider adding a time-lock for such changes.
StatusUnresolved
Medium

`antiFarmerExpirationTime` `uint48` Overflow Risk

M-02The `antiFarmerExpirationTime` variable is declared as `uint48`. While `block.timestamp` is currently well within `uint48` limits, in approximately 17,000 years, `block.timestamp` will exceed the maximum value of `uint48`. At that point, `block.timestamp + antiFarmerDuration` could cause an overflow when cast to `uint48`, leading to incorrect expiration calculations and unexpected contract behavior (7.2 Code Security).
IssueThe `antiFarmerExpirationTime` variable is declared as `uint48`. While `block.timestamp` is currently well within `uint48` limits, in approximately 17,000 years, `block.timestamp` will exceed the maximum value of `uint48`. At that point, `block.timestamp + antiFarmerDuration` could cause an overflow when cast to `uint48`, leading to incorrect expiration calculations and unexpected contract behavior (7.2 Code Security).
FixConsider using `uint64` for `antiFarmerExpirationTime`, similar to `taxExpirationTime`, to provide a significantly longer operational lifespan and prevent future overflow issues.
StatusUnresolved
Low

Lack of Event Emission for Tax Rate Changes

L-01While `PoolStateChanged` is emitted when the overall pool state changes, there are no explicit events emitted when `buyTaxRate` or `sellTaxRate` are modified within the `_liquidateTax` function (e.g., when the state transitions to `TaxFree` and rates are set to 0). This lack of granular event emission makes it harder for off-chain monitoring systems and users to track precise tax rate changes (7.2 Code Security, 7.8 Operations).
IssueWhile `PoolStateChanged` is emitted when the overall pool state changes, there are no explicit events emitted when `buyTaxRate` or `sellTaxRate` are modified within the `_liquidateTax` function (e.g., when the state transitions to `TaxFree` and rates are set to 0). This lack of granular event emission makes it harder for off-chain monitoring systems and users to track precise tax rate changes (7.2 Code Security, 7.8 Operations).
FixEmit specific events (e.g., `TaxRatesChanged(uint16 newBuyTax, uint16 newSellTax)`) whenever `buyTaxRate` or `sellTaxRate` are modified to enhance transparency and off-chain monitoring capabilities.
StatusUnresolved
Info

Initial Token Distribution Centralization

I-01The `initialize` function mints the entire `maxSupply` (1 billion tokens) to `msg.sender` (the deployer/initializer address). This centralizes the initial token supply entirely with one address, which then bears the responsibility for subsequent distribution. While a common pattern, it concentrates significant power and responsibility (7.4 Economic).
IssueThe `initialize` function mints the entire `maxSupply` (1 billion tokens) to `msg.sender` (the deployer/initializer address). This centralizes the initial token supply entirely with one address, which then bears the responsibility for subsequent distribution. While a common pattern, it concentrates significant power and responsibility (7.4 Economic).
FixEnsure that the address receiving the initial `maxSupply` is a secure, multi-signature wallet or a well-audited distribution contract to mitigate risks associated with a single point of control.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's upgradeable standards for ERC20, Ownable, and Permit functionalities, contributing to a robust architectural foundation (7.1 Architecture). `SafeERC20` is correctly used for external token interactions. However, a critical security concern arises from the truncated `_liquidateTax` function, which is called on every transfer and prevents a full security assessment of its complex logic, including potential reentrancy or external call issues (7.2 Code Security). Additionally, the `uint48` type for `antiFarmerExpirationTime` introduces a long-term overflow risk.

GovernanceHigh3/10

The contract's economic model incorporates dynamic tax rates and anti-farmer mechanisms, managed through various `PoolState` transitions. The owner has significant control over these transitions via `startMigration` and `finalizeMigration` functions, posing a centralization risk (7.3 Access Control, 7.5 Governance). The `_liquidateTax` function, which modifies tax rates and states based on `block.timestamp` and contract balance, introduces potential for manipulation and high gas costs on every transfer (7.4 Economic). The initial minting of `maxSupply` to the deployer also centralizes initial token distribution.

UpgradesLow8/10

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's `Initializable` and `_disableInitializers` in the constructor, ensuring proper upgradeability (7.7 Upgrades). The `onlyOwner` modifier protects the upgrade mechanism (implicitly, as the owner controls the proxy admin), which is standard for UUPS. This design allows for future enhancements or bug fixes, but also means the owner retains significant control over the contract's evolution.

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

17.0% in top 10
2.0% in wallets15.0% in contracts
Effective Concentration8.0%

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

$90.2K across 2 pairs
Pancakeswap v2QQQBanalysed$90.1K100.0%Pancakeswap v3USDT$290.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
0x3127…e025
Unlocked LP Held By
0x6b89…70d1

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

What Raised This Score

8 factors
  • 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
  • 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
VelvetHigh RiskUcan fix life in1day (1)High RiskCookieHigh RiskCrossHigh RiskBicatHigh Riskb-moneyHigh 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