Quantum Audit Logo
Launch App

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

Is Giggle Cat a Scam?

NIANNIANBNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on recordNew Launch · 6d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance6/10Upgrades5/10Checks passed5 of 7Findings1 High · 2 Medium · 2 Low · 1 Info6
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms, anti-farmer features, and a multi-state pool management system.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity < $50k
  • Token age < 7 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

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.

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax5% / 5%

Holders

as of audit · Sep 4, 2026
35.5%Contracts17.9%Wallets46.6%Everyone else
35.5%Contracts17.9%Wallets46.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
53.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.5%
  • Walletsanonymous holders, free to sell17.9%
  • Everyone elsethe rest of the supply46.6%
Effective concentrationwhat the score reads32.1%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$23.4K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$23.4KShare of depth100.0%
LP Burned99.6% · ≈ permanent lock
LP Locked99.6% · Null Address
Unlocked LP held by
0x0ed9…9706

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

Security Findings

1 High2 Medium2 Low1 Info
High

Centralization Risk with Owner Privileges

The 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.H-01

Issue

The 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.

Fix

Implement 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.

Status

Unresolved

Medium

Dependency on External ITaxProcessor and IDividend Contracts

The 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.M-01

Issue

The 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.

Fix

Conduct 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.

Status

Unresolved

Medium

Potential for Stuck Funds if _processTax Fails

The _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.M-02

Issue

The _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.

Fix

Implement 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.

Status

Unresolved

Low

antiFarmerExpirationTime Overflow Risk

The 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.L-01

Issue

The 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.

Fix

Add 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");`

Status

Unresolved

Low

taxExpirationTime Overflow Risk

The 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.L-02

Issue

The 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.

Fix

Add 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");`

Status

Unresolved

Info

_plainTransfer Function Visibility

The _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.I-01

Issue

The _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.

Fix

No 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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).

Governance6/10Medium risk

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).

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to implement a multi-signature wallet or a time-lock for critical owner-controlled functions to mitigate centralization risks.

Thoroughly audit and secure all external contract dependencies, especially the ITaxProcessor and IDividend contracts, as their integrity is crucial for the token's functionality. Consider adding a recovery mechanism or robust error handling for collected tax funds in case external calls to _processTax fail.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age6d
Contract0xcb74…7777
Deployer0x1ad3…766b
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Giggle Cat security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202643Medium
  2. Aug 30, 202619Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
GUABNB Chain43MediumTrenchesStarterPack战壕入门包 · BNB Chain43MediumChainbase TokenC · BNB Chain43MediummemestockBNB Chain43MediumBabySharkBNB Chain43MediumUPONLYBNB Chain43Medium

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 Is this your token? Publish your own audit on this page