Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Giggle Mascot Safe?

MAXBNB 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 record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance9/10Upgrades5/10Checks passed4 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The FlapTaxTokenV3 contract is an upgradeable ERC20 token designed with a dynamic tax mechanism, anti-farmer features, and a state machine to manage its lifecycle.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Token age < 30 days (still settling)
  • 1 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
10.1%Contracts8.9%Wallets81.0%Everyone else
10.1%8.9%81.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
19.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking10.1%
  • Walletsanonymous holders, free to sell8.9%
  • Everyone elsethe rest of the supply81.0%
Effective concentrationwhat the score reads12.9%
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$505.1K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$490.8KShare of depth97.2%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x00f9…1bcd

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralization of Control

The Owner role has significant control over critical contract parameters and state transitions. Functions like startMigration, finalizeMigration, and the ability to set taxProcessor, dividendContract, v2Router, quoteToken, and pools are restricted to the owner. This centralization introduces a single point of failure and a high trust assumption in the owner's integrity and operational security, as a compromised owner key could lead to severe economic manipulation or system disruption.H-01

Issue

The Owner role has significant control over critical contract parameters and state transitions. Functions like startMigration, finalizeMigration, and the ability to set taxProcessor, dividendContract, v2Router, quoteToken, and pools are restricted to the owner. This centralization introduces a single point of failure and a high trust assumption in the owner's integrity and operational security, as a compromised owner key could lead to severe economic manipulation or system disruption.

Fix

Consider implementing a multi-signature wallet for the Owner role to distribute control and enhance security. For highly sensitive operations, explore mechanisms for decentralized governance or time-locked changes to provide transparency and allow community oversight.

Status

Unresolved

Medium

Potential Integer Overflow in antiFarmerExpirationTime

The antiFarmerExpirationTime is stored as a uint48. In the finalizeMigration function, this value is set by block.timestamp + antiFarmerDuration. If block.timestamp + antiFarmerDuration exceeds the maximum value of uint48 (approximately 2.8e14 seconds or ~8921 years from epoch), an integer overflow will occur. This would result in an incorrect, much smaller expiration time, potentially disrupting the intended anti-farmer mechanism and leading to unexpected behavior.M-01

Issue

The antiFarmerExpirationTime is stored as a uint48. In the finalizeMigration function, this value is set by block.timestamp + antiFarmerDuration. If block.timestamp + antiFarmerDuration exceeds the maximum value of uint48 (approximately 2.8e14 seconds or ~8921 years from epoch), an integer overflow will occur. This would result in an incorrect, much smaller expiration time, potentially disrupting the intended anti-farmer mechanism and leading to unexpected behavior.

Fix

Implement a require statement to ensure that block.timestamp + antiFarmerDuration does not exceed type(uint48).max. Alternatively, consider using a larger integer type (e.g., uint64) for antiFarmerExpirationTime if the intended duration could realistically exceed the uint48 limit.

Status

Unresolved

Medium

Critical External Dependencies

The FlapTaxTokenV3 contract relies heavily on external contracts, specifically ITaxProcessor and IDividend, for its core tax processing and dividend distribution logic. The security and correctness of these external contracts are paramount to the overall system's integrity. If these external contracts contain vulnerabilities, are maliciously implemented, or are controlled by a compromised entity, they could lead to fund loss, incorrect tax calculations, or disruption of dividend distribution.M-02

Issue

The FlapTaxTokenV3 contract relies heavily on external contracts, specifically ITaxProcessor and IDividend, for its core tax processing and dividend distribution logic. The security and correctness of these external contracts are paramount to the overall system's integrity. If these external contracts contain vulnerabilities, are maliciously implemented, or are controlled by a compromised entity, they could lead to fund loss, incorrect tax calculations, or disruption of dividend distribution.

Fix

Conduct thorough security audits of the ITaxProcessor and IDividend contracts. Ensure that their implementations are robust, secure, and align with the expected behavior. Implement strict access control on these external contracts and consider mechanisms to update their addresses safely in case of a vulnerability or upgrade.

Status

Unresolved

Low

Storage Collision Risk in Upgrades

While the contract correctly uses OpenZeppelin's Initializable pattern for upgradeability, adding new state variables to the contract in future implementations without careful consideration of storage slot packing, especially with the PackedPoolState struct, could lead to storage collisions. If new variables are inserted before existing ones or if the PackedPoolState struct's internal layout changes in a way that shifts its slot, it could corrupt existing data.L-01

Issue

While the contract correctly uses OpenZeppelin's Initializable pattern for upgradeability, adding new state variables to the contract in future implementations without careful consideration of storage slot packing, especially with the PackedPoolState struct, could lead to storage collisions. If new variables are inserted before existing ones or if the PackedPoolState struct's internal layout changes in a way that shifts its slot, it could corrupt existing data.

Fix

Adhere strictly to OpenZeppelin's upgradeable storage layout guidelines. When adding new state variables, always append them to the end of the contract's storage. For complex structs like PackedPoolState, ensure any modifications are backward-compatible or use a dedicated storage gap to prevent future collisions.

Status

Unresolved

Info

Gas Inefficiency in _liquidateTax State Updates

The _liquidateTax function reads poolState into a local variable currentPoolState, modifies it, writes it back to storage (poolState = currentPoolState), then reads it again (after the external call), modifies it, and writes it back again. While the multiple reads and writes are part of a robust reentrancy guard, this pattern involves multiple SLOAD and SSTORE operations within a single function call. This could be slightly optimized for gas by consolidating storage writes if the reentrancy guard logic allows for it without compromising security.I-01

Issue

The _liquidateTax function reads poolState into a local variable currentPoolState, modifies it, writes it back to storage (poolState = currentPoolState), then reads it again (after the external call), modifies it, and writes it back again. While the multiple reads and writes are part of a robust reentrancy guard, this pattern involves multiple SLOAD and SSTORE operations within a single function call. This could be slightly optimized for gas by consolidating storage writes if the reentrancy guard logic allows for it without compromising security.

Fix

Review the _liquidateTax function to determine if the poolState variable can be written to storage fewer times without compromising the reentrancy guard. For example, if the second currentPoolState = poolState; read is not strictly necessary for security after the external call, the final poolState = currentPoolState; could potentially be combined.

Status

Unresolved

Analysis

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

The FlapTaxTokenV3 contract is an upgradeable ERC20 token designed with a dynamic tax mechanism, anti-farmer features, and a state machine to manage its lifecycle. It leverages OpenZeppelin's upgradeable contracts for robustness. The audit identified a high level of centralization of control by the owner, critical dependencies on external contracts, and a potential integer overflow in a time-based calculation. The contract implements reentrancy guards for its tax liquidation process, which is a positive security practice.

Technical8/10Low risk

The contract demonstrates good technical architecture, utilizing OpenZeppelin's upgradeable standards and a well-defined state machine for its tax and anti-farmer mechanisms. The _liquidateTax function includes a robust reentrancy guard using a notLiquidating flag, which is crucial given its external calls. However, a potential integer overflow exists in the antiFarmerExpirationTime calculation, which could lead to incorrect anti-farmer logic (7.2 Code Security). Additionally, the system's reliance on external ITaxProcessor and IDividend contracts introduces significant external dependency risks (7.6 External).

Governance9/10Low risk

The contract exhibits a high degree of centralization, with the Owner role possessing extensive control over critical parameters and state transitions (7.5 Governance). The owner can initiate migration phases, set addresses for the taxProcessor, dividendContract, v2Router, and quoteToken, and define pools. This centralized control means the economic model and core functionality are heavily dependent on the owner's integrity and operational security (7.4 Economic).

Upgrades5/10Medium risk

The contract correctly implements OpenZeppelin's Initializable pattern for upgradeability, including _disableInitializers() in the constructor and the initializer modifier. However, as with all proxy implementations, future upgrades must carefully manage storage layout to prevent collisions, especially considering the PackedPoolState struct (7.7 Upgrades). Adding new state variables without proper slot management could lead to unexpected behavior or data corruption.

Final RecommendationWhat to do about this score

It is recommended to implement robust validation and constraints for input parameters, particularly for time-related values, to prevent potential overflows.

A comprehensive audit of all external dependencies, specifically the ITaxProcessor and IDividend contracts, is crucial to ensure the overall security and economic stability of the system. Consider decentralizing critical owner-controlled functions or implementing a multi-signature wallet for sensitive operations to mitigate centralization risks.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age10d
Contract0xe9bc…7777
Deployer0x182c…4f58
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Giggle Mascot 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, 202613Low
  2. Aug 11, 202616Low

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

Frequently Asked Questions

What is the MAX contract address?

The Giggle Mascot (MAX) contract on BNB Chain is 0xe9bc5c6a86caa44fd7b469bf3cc7c563e4f77777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Giggle Mascot a scam?

Quantum Audit's risk score for Giggle Mascot is 13/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is MAX liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $505.1K.

Who holds MAX?

As of Sep 4, 2026, the 10 largest holders own 19.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
FrippyBNB Chain13LowOKZOOAIOT · BNB Chain13LowBinance CatBNBCAT · BNB Chain13LowNianNianBNB Chain13LowARIA.AIARIA · BNB Chain12LowBreak And ReclaimBAN · BNB Chain14Low

Would You Like a More Detailed Audit of Giggle Mascot?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page