Quantum Audit Logo

Is Giggle Tom a Scam?

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

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

Giggle Tom TOM
0x7b87…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 10h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex state-based tax mechanism and an integrated tax liquidation process. The audit identified critical vulnerabilities, including reentrancy and denial-of-service risks stemming from external calls within the transfer function. High-severity issues relate to the immutability of critical parameters and significant centralization risks. Medium-severity findings include the lack of an emergency pause and potential MEV exposure during tax processing. The contract utilizes OpenZeppelin's upgradeable patterns, which is a positive aspect, but the identified critical flaws require immediate attention.

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

Security Findings

2 Crit2 High2 Med1 Low1 Info
Critical

Reentrancy Vulnerability in `_liquidateTax`

C-01The `_liquidateTax` function, which is called during every `_transfer`, makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distribute`. These calls occur before the contract's internal state (e.g., `balanceOf(address(this))`) is fully updated or protected by a reentrancy guard. A malicious `taxProcessor` or `dividendContract` could reenter the `_transfer` or `_liquidateTax` function, potentially leading to double-spending of collected tax funds or manipulation of the contract's state.
IssueThe `_liquidateTax` function, which is called during every `_transfer`, makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distribute`. These calls occur before the contract's internal state (e.g., `balanceOf(address(this))`) is fully updated or protected by a reentrancy guard. A malicious `taxProcessor` or `dividendContract` could reenter the `_transfer` or `_liquidateTax` function, potentially leading to double-spending of collected tax funds or manipulation of the contract's state.
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on the `_liquidateTax` function. Alternatively, ensure that all state changes related to tax collection and liquidation are completed following the 'checks-effects-interactions' pattern before any external calls are made.
StatusUnresolved
Critical

Denial of Service via External Call Reverts

C-02The `_liquidateTax` function, which is an integral part of the `_transfer` flow, makes external calls to `taxProcessor` and `dividendContract`. If either of these external contracts reverts (e.g., due to an error, intentional malicious behavior, or being paused), all token transfers (`_transfer`) will consequently revert. This effectively halts the entire token's functionality, leading to a complete denial of service for all users.
IssueThe `_liquidateTax` function, which is an integral part of the `_transfer` flow, makes external calls to `taxProcessor` and `dividendContract`. If either of these external contracts reverts (e.g., due to an error, intentional malicious behavior, or being paused), all token transfers (`_transfer`) will consequently revert. This effectively halts the entire token's functionality, leading to a complete denial of service for all users.
FixImplement robust error handling for external calls. Consider using a pull-based mechanism for tax distribution where external parties claim funds, rather than pushing funds directly within the critical transfer path. Alternatively, allow the owner to remove or replace a problematic `taxProcessor` or `dividendContract` to prevent a full DoS, possibly by wrapping external calls in `try/catch` blocks if partial failure is acceptable.
StatusUnresolved
High

Rigid Critical Parameters

H-01Numerous critical operational parameters, including `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `liqExpectedOutputAmount`, `antiFarmerDuration`, `buyTaxRate`, `sellTaxRate`, `taxDuration`, and the `pools` mapping, are set exclusively during the `initialize` function and are immutable thereafter. This rigidity prevents the contract from adapting to changing market conditions, security threats, or evolving protocol needs without a full contract upgrade, increasing operational risk.
IssueNumerous critical operational parameters, including `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `liqExpectedOutputAmount`, `antiFarmerDuration`, `buyTaxRate`, `sellTaxRate`, `taxDuration`, and the `pools` mapping, are set exclusively during the `initialize` function and are immutable thereafter. This rigidity prevents the contract from adapting to changing market conditions, security threats, or evolving protocol needs without a full contract upgrade, increasing operational risk.
FixImplement owner-controlled functions to update critical parameters (e.g., `setTaxProcessor`, `setDividendContract`, `setBuyTaxRate`, `setSellTaxRate`, `addPool`, `removePool`). These functions should include appropriate access controls (e.g., `onlyOwner`) and potentially time-locks or multi-signature approvals for sensitive changes to enhance security and flexibility.
StatusUnresolved
High

Centralization Risk and Single Point of Failure

H-02The contract relies heavily on the `owner` for critical state transitions (`startMigration`, `finalizeMigration`). Furthermore, the `taxProcessor` and `dividendContract` are fixed external dependencies. If the owner's private key is compromised, or if the `taxProcessor` or `dividendContract` are malicious or exploited, the system faces a single point of failure that could lead to fund loss, manipulation, or a complete halt of operations.
IssueThe contract relies heavily on the `owner` for critical state transitions (`startMigration`, `finalizeMigration`). Furthermore, the `taxProcessor` and `dividendContract` are fixed external dependencies. If the owner's private key is compromised, or if the `taxProcessor` or `dividendContract` are malicious or exploited, the system faces a single point of failure that could lead to fund loss, manipulation, or a complete halt of operations.
FixConsider implementing a multi-signature wallet for ownership to reduce the risk of a single point of compromise. For external dependencies, explore mechanisms for owner-controlled updates (as in H-01) and potentially a circuit breaker or emergency pause to mitigate risks from compromised external contracts.
StatusUnresolved
Medium

Lack of Emergency Pause Mechanism

M-01The contract lacks an emergency pause mechanism. In the event of a critical vulnerability, exploit, or unforeseen issue, there is no way for the owner or a governance body to temporarily halt transfers or other critical operations to prevent further damage or allow for a fix.
IssueThe contract lacks an emergency pause mechanism. In the event of a critical vulnerability, exploit, or unforeseen issue, there is no way for the owner or a governance body to temporarily halt transfers or other critical operations to prevent further damage or allow for a fix.
FixIntegrate an emergency pause mechanism (e.g., OpenZeppelin's `PausableUpgradeable` contract). This would allow the owner to pause critical functions like `_transfer` in an emergency, providing time to address issues or prepare for an upgrade.
StatusUnresolved
Medium

MEV Risk in Tax Processing

M-02The `_liquidateTax` function calls `ITaxProcessor(taxProcessor).processTax(taxAmount, liqExpectedOutputAmount, quoteToken, v2Router)`. This likely involves a swap operation on a DEX. Such operations are susceptible to Miner Extractable Value (MEV) attacks, specifically sandwich attacks, where malicious actors can front-run and back-run the transaction to profit at the expense of the protocol, potentially reducing the effective value of the collected tax.
IssueThe `_liquidateTax` function calls `ITaxProcessor(taxProcessor).processTax(taxAmount, liqExpectedOutputAmount, quoteToken, v2Router)`. This likely involves a swap operation on a DEX. Such operations are susceptible to Miner Extractable Value (MEV) attacks, specifically sandwich attacks, where malicious actors can front-run and back-run the transaction to profit at the expense of the protocol, potentially reducing the effective value of the collected tax.
FixWhile completely eliminating MEV is challenging, consider strategies to mitigate its impact. This could include using a decentralized exchange aggregator that routes through multiple liquidity sources, implementing a minimum output amount check with slippage control, or exploring private transaction relays for sensitive operations.
StatusUnresolved
Low

Reliance on `block.timestamp` for Critical Logic

L-01The `_liquidateTax` function uses `block.timestamp` to determine state transitions (e.g., `taxExpirationTime`, `antiFarmerExpirationTime`). While common, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner to slightly accelerate or delay a state change to their advantage, though the impact might be limited for expiration times.
IssueThe `_liquidateTax` function uses `block.timestamp` to determine state transitions (e.g., `taxExpirationTime`, `antiFarmerExpirationTime`). While common, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner to slightly accelerate or delay a state change to their advantage, though the impact might be limited for expiration times.
FixBe aware of the limitations of `block.timestamp`. For critical, time-sensitive operations where precise timing is crucial and manipulation could lead to significant gains, consider using alternative time sources or mechanisms that are less susceptible to miner manipulation, such as a time oracle or a commit-reveal scheme. For expiration times, the risk is generally lower.
StatusUnresolved
Info

No Token Recovery Mechanism

I-01The contract does not include a function to recover accidentally sent ERC20 tokens (other than its own token) that might be mistakenly transferred to the contract address. Such tokens would become permanently locked and inaccessible.
IssueThe contract does not include a function to recover accidentally sent ERC20 tokens (other than its own token) that might be mistakenly transferred to the contract address. Such tokens would become permanently locked and inaccessible.
FixImplement an `onlyOwner` function to allow the recovery of arbitrary ERC20 tokens sent to the contract address. This function should explicitly exclude the contract's own token to prevent accidental draining.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract leverages OpenZeppelin's upgradeable ERC20 standard and implements a detailed state machine for managing token taxes and migrations (7.1 Architecture). Code quality is generally good, with clear structure and gas-efficient state packing. However, critical vulnerabilities were identified in 7.2 Code Security, specifically reentrancy and denial-of-service risks due to unprotected external calls within the core transfer logic. Additionally, the tax processing mechanism may be susceptible to MEV attacks.

GovernanceHigh3/10

The contract's economic model relies on a state-based tax mechanism and a liquidation process that distributes collected taxes (7.4 Economic). The owner has control over state transitions (7.5 Governance). A significant weakness is the immutability of critical parameters like tax rates, `taxProcessor`, and `dividendContract` after initialization, which severely limits adaptability. This also introduces a high centralization risk and single point of failure if the owner or external dependencies are compromised (7.3 Access Control, 7.6 External).

UpgradesHigh3/10

The contract correctly implements the OpenZeppelin upgradeable pattern, including `Initializable` and `_disableInitializers()` in the constructor (7.7 Upgrades). This allows for future logic updates. However, the immutability of many critical parameters means that even minor adjustments to the protocol's core functionality would necessitate a full contract upgrade, increasing operational overhead and potential for errors.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

54.6% in top 10
4.5% in wallets50.1% in contracts
Effective Concentration24.5%

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

$14.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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0x8353…c348

What Raised This Score

9 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (54.6% total → 24.5% effective; 4.5% in EOAs, 50.1% in contracts — mild)
  • Liquidity < $50k ($14,382 across 1 pairs — thin market)
  • Token age < 24h (brand new — bot activity, unproven)
  • 2 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
NVIDIA Corp (NVDAB)Critical RiskUnited Stables (U)Critical RiskCATCritical RiskMITOCritical RiskBased Token (BASED)Critical RiskDexeCritical Risk

Would You Like a More Detailed Audit of Giggle Tom?

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

Get Detailed Audit