Quantum Audit Logo

Is Giggle Cat a Scam?

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

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

Giggle Cat NIANNIAN
0xcb74…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 6d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms, anti-farmer features, and a multi-state pool management system. It leverages OpenZeppelin's upgradeable contracts for security and modularity. The contract includes a reentrancy guard for external calls during tax liquidation. Key areas of concern include the significant control vested in the owner and the reliance on external contracts for core tax processing and dividend distribution, which introduces dependencies and potential points of failure.

1 High2 Medium2 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
$8.2K
Liquidity
$23.4K
Price
$0.00003926
Token Age
6d
Top 10 Holders
53.4%

Security Findings

1 High2 Med2 Low1 Info
High

Centralization Risk with Owner Privileges

H-01The `owner` role has significant control over the contract's operational state, specifically through the `startMigration()` and `finalizeMigration()` functions. These functions allow the owner to transition the token's state from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`, which directly impacts tax collection and anti-farmer mechanisms. This level of control introduces a single point of failure and potential for malicious or erroneous state changes by a compromised owner key.
IssueThe `owner` role has significant control over the contract's operational state, specifically through the `startMigration()` and `finalizeMigration()` functions. These functions allow the owner to transition the token's state from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`, which directly impacts tax collection and anti-farmer mechanisms. This level of control introduces a single point of failure and potential for malicious or erroneous state changes by a compromised owner key.
FixImplement a multi-signature wallet for the `owner` role to require multiple approvals for critical state-changing functions. Alternatively, consider a time-lock mechanism to introduce a delay before such operations take effect, allowing for community review or intervention.
StatusUnresolved
Medium

Dependency on External `ITaxProcessor` and `IDividend` Contracts

M-01The contract relies heavily on external contracts (`taxProcessor` and `dividendContract`) for core functionalities such as processing collected taxes and distributing dividends. The `_processTax` function, which is critical for the token's economic model, makes an external call to `ITaxProcessor.processTax`. If these external contracts are malicious, buggy, or become inaccessible, the entire tax and dividend distribution system could fail, leading to loss of funds or system instability.
IssueThe contract relies heavily on external contracts (`taxProcessor` and `dividendContract`) for core functionalities such as processing collected taxes and distributing dividends. The `_processTax` function, which is critical for the token's economic model, makes an external call to `ITaxProcessor.processTax`. If these external contracts are malicious, buggy, or become inaccessible, the entire tax and dividend distribution system could fail, leading to loss of funds or system instability.
FixConduct a comprehensive security audit of the `ITaxProcessor` and `IDividend` contracts to ensure their integrity and robustness. Implement robust monitoring for these external dependencies. Consider adding circuit breakers or emergency stop mechanisms that can temporarily disable tax processing if issues are detected with the external contracts.
StatusUnresolved
Medium

Potential for Stuck Funds if `_processTax` Fails

M-02The `_liquidateTax` function collects tax tokens into the contract's balance and then attempts to process them by calling `ITaxProcessor.processTax(taxAmount)`. If this external call to the `taxProcessor` contract reverts or fails for any reason (e.g., due to a bug in the `taxProcessor`, insufficient gas, or an intentional block), the collected `taxAmount` will remain in the `FlapTaxTokenV3` contract. Without a specific recovery mechanism, these funds could accumulate and become permanently inaccessible.
IssueThe `_liquidateTax` function collects tax tokens into the contract's balance and then attempts to process them by calling `ITaxProcessor.processTax(taxAmount)`. If this external call to the `taxProcessor` contract reverts or fails for any reason (e.g., due to a bug in the `taxProcessor`, insufficient gas, or an intentional block), the collected `taxAmount` will remain in the `FlapTaxTokenV3` contract. Without a specific recovery mechanism, these funds could accumulate and become permanently inaccessible.
FixImplement a recovery function, callable by the owner, to withdraw any accumulated tax tokens from the contract in case of `_processTax` failures. Alternatively, consider wrapping the external call in a `try/catch` block to handle failures gracefully, perhaps by logging the event and allowing the transaction to proceed without processing tax, or by temporarily disabling tax collection until the issue is resolved.
StatusUnresolved
Low

`antiFarmerExpirationTime` Overflow Risk

L-01The `antiFarmerExpirationTime` is stored as a `uint48`. In `finalizeMigration()`, it is set by `block.timestamp + antiFarmerDuration`. While `uint48` provides sufficient range for many years (approximately 8.9 million years), `block.timestamp` is a `uint256`. If `block.timestamp + antiFarmerDuration` were to exceed the maximum value of `uint48`, the value would silently truncate due to implicit conversion, leading to an incorrect (and potentially much earlier) expiration time.
IssueThe `antiFarmerExpirationTime` is stored as a `uint48`. In `finalizeMigration()`, it is set by `block.timestamp + antiFarmerDuration`. While `uint48` provides sufficient range for many years (approximately 8.9 million years), `block.timestamp` is a `uint256`. If `block.timestamp + antiFarmerDuration` were to exceed the maximum value of `uint48`, the value would silently truncate due to implicit conversion, leading to an incorrect (and potentially much earlier) expiration time.
FixAdd an explicit `require` check to ensure that `block.timestamp + antiFarmerDuration` does not exceed `type(uint48).max` before assignment. For example: `require(block.timestamp + antiFarmerDuration <= type(uint48).max, "Anti-farmer expiration time exceeds uint48 max");`
StatusUnresolved
Low

`taxExpirationTime` Overflow Risk

L-02The `taxExpirationTime` is stored as a `uint64`. In `finalizeMigration()`, it is updated by `currentPoolState.taxExpirationTime + block.timestamp`. If `currentPoolState.taxExpirationTime` already holds a large value (e.g., from previous additions) and `block.timestamp` is also large, their sum could theoretically exceed `type(uint64).max`. This would result in an integer overflow, leading to an incorrect (and potentially much earlier) expiration time.
IssueThe `taxExpirationTime` is stored as a `uint64`. In `finalizeMigration()`, it is updated by `currentPoolState.taxExpirationTime + block.timestamp`. If `currentPoolState.taxExpirationTime` already holds a large value (e.g., from previous additions) and `block.timestamp` is also large, their sum could theoretically exceed `type(uint64).max`. This would result in an integer overflow, leading to an incorrect (and potentially much earlier) expiration time.
FixAdd an explicit `require` check to ensure that `currentPoolState.taxExpirationTime + block.timestamp` does not exceed `type(uint64).max` before assignment. For example: `require(currentPoolState.taxExpirationTime + block.timestamp <= type(uint64).max, "Tax expiration time exceeds uint64 max");`
StatusUnresolved
Info

`_plainTransfer` Function Visibility

I-01The `_plainTransfer` function is declared as `internal`. This function serves as a wrapper for `super._transfer` without applying any tax logic. While its current `internal` visibility is appropriate for its usage within the contract, it means no external entity or even derived contracts (without specific inheritance patterns) can directly call a non-taxed transfer. This is an architectural choice that might limit flexibility if a public non-taxed transfer mechanism were ever desired for specific scenarios or roles.
IssueThe `_plainTransfer` function is declared as `internal`. This function serves as a wrapper for `super._transfer` without applying any tax logic. While its current `internal` visibility is appropriate for its usage within the contract, it means no external entity or even derived contracts (without specific inheritance patterns) can directly call a non-taxed transfer. This is an architectural choice that might limit flexibility if a public non-taxed transfer mechanism were ever desired for specific scenarios or roles.
FixNo immediate action is required. This is an observation regarding design choice. If future requirements include allowing specific roles or external contracts to perform non-taxed transfers, consider creating a new public/external function with appropriate access control that calls `_plainTransfer`.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical practices, utilizing OpenZeppelin's upgradeable standards and implementing a reentrancy guard (`notLiquidating` flag) for external calls in `_liquidateTax` (7.2 Code Security). The `PackedPoolState` struct is gas-efficient. However, the contract's core functionality relies on external `ITaxProcessor` and `IDividend` contracts (7.6 External), introducing a dependency risk. There is also a potential for collected tax funds to become stuck if the external `_processTax` call fails (7.2 Code Security).

GovernanceMedium6/10

The economic model is centered around dynamic buy/sell taxes and an anti-farmer mechanism, with immutable liquidation thresholds (`MIN_LIQ_THRESHOLD`, `START_LIQ_THRESHOLD`) providing some stability (7.4 Economic). However, the `owner` role holds significant power, including the ability to initiate and finalize migration, which directly impacts the token's economic state and tax enforcement (7.3 Access Control, 7.5 Governance). The reliance on external tax and dividend contracts also introduces economic risk if these dependencies are compromised or misconfigured (7.6 External).

UpgradesMedium5/10

The contract is designed for upgradeability, inheriting from `Initializable` and using OpenZeppelin's upgradeable ERC20 and Ownable contracts. The `_disableInitializers()` call in the constructor and explicit initializer functions (`initialize`) follow best practices for proxy patterns (7.7 Upgrades). This setup allows for future enhancements and bug fixes without redeploying the entire system.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

53.4% in top 10
17.9% in wallets35.5% in contracts
Effective Concentration32.1%

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

$23.4K

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 Burned99.6% · ≈ permanent lock
LP Locked99.6% · Null Address

Key Addresses

2 addresses
Deployer
0x1ad3…766b
Unlocked LP Held By
0x0ed9…9706

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

What Raised This Score

8 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 30% (53.4% total → 32.1% effective; 17.9% in EOAs, 35.5% in contracts — moderate)
  • Liquidity < $50k ($23,351 across 1 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
GUAMedium RiskTrenchesStarterPack (战壕入门包)Medium RiskChainbase Token (C)Medium RiskmemestockMedium RiskBabySharkMedium Risk吉祥马Medium Risk

Would You Like a More Detailed Audit of Giggle Cat?

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

Get Detailed Audit