Quantum Audit Logo

Is Giggle Mascot Safe?

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

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

Giggle Mascot MAX
0xe9bc…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive 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. 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.

1 High2 Medium1 Low1 Informational
Volume 24h
$3.15M
Liquidity
$490.8K
Price
$0.01373
Token Age
10d
Top 10 Holders
19.0%

Security Findings

1 High2 Med1 Low1 Info
High

Centralization of Control

H-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Potential Integer Overflow in `antiFarmerExpirationTime`

M-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Critical External Dependencies

M-02The `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.
IssueThe `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.
FixConduct 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.
StatusUnresolved
Low

Storage Collision Risk in Upgrades

L-01While 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.
IssueWhile 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.
FixAdhere 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.
StatusUnresolved
Info

Gas Inefficiency in `_liquidateTax` State Updates

I-01The `_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.
IssueThe `_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.
FixReview 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow9/10

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

UpgradesMedium5/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

19.0% in top 10
8.9% in wallets10.1% in contracts
Effective Concentration12.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

$505.1K across 3 pairs
Pancakeswap v2WBNBanalysed$490.8K97.2%Pancakeswap v3USDT$14.3K2.8%Uniswap v2USDT$270.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

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

Key Addresses

2 addresses
Deployer
0x182c…4f58
Unlocked LP Held By
0x00f9…1bcd

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

What Raised This Score

6 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

Related Audits

6 more on the record
FrippyLow RiskOKZOO (AIOT)Low RiskBinance Cat (BNBCAT)Low RiskNianNianLow RiskARIA.AI (ARIA)Low RiskBuild On BNB (BOB)Low Risk

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