Quantum Audit Logo
Launch App

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

Is Giggle Tom a Scam?

TOMBNB 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 · 10h old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical3/10Governance3/10Upgrades3/10Checks passed5 of 7Findings2 Critical · 2 High · 2 Medium · 1 Low · 1 Info8
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex state-based tax mechanism and an integrated tax liquidation process.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Liquidity < $50k
  • Token age < 24h
  • 2 Critical finding(s) from audit
  • 2 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)
  • 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

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.

Security Checklist

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

Holders

as of audit · Sep 4, 2026
50.1%Contracts4.5%Wallets45.4%Everyone else
50.1%Contracts4.5%45.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
54.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking50.1%
  • Walletsanonymous holders, free to sell4.5%
  • Everyone elsethe rest of the supply45.4%
Effective concentrationwhat the score reads24.5%
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$14.4K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$14.4KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

2 Critical2 High2 Medium1 Low1 Info
Critical

Reentrancy Vulnerability in _liquidateTax

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

Issue

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

Fix

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

Status

Unresolved

Critical

Denial of Service via External Call Reverts

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

Issue

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

Fix

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

Status

Unresolved

High

Rigid Critical Parameters

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

Issue

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

Fix

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

Status

Unresolved

High

Centralization Risk and Single Point of Failure

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

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of Emergency Pause Mechanism

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

Issue

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

Fix

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

Status

Unresolved

Medium

MEV Risk in Tax Processing

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

Issue

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

Fix

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

Status

Unresolved

Low

Reliance on block.timestamp for Critical Logic

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

Issue

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

Fix

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

Status

Unresolved

Info

No Token Recovery Mechanism

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

Issue

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

Fix

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

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

Technical3/10High risk

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.

Governance3/10High risk

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

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Address the critical reentrancy and denial-of-service vulnerabilities immediately by implementing reentrancy guards and robust error handling for external calls.

Enhance the contract's flexibility by introducing owner-controlled functions to update critical parameters, ideally with time-locks or multi-signature approvals. Implement an emergency pause mechanism to mitigate risks during unforeseen events. Consider strategies to reduce MEV impact on tax processing and add a function for recovering accidentally sent tokens.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age10h
Contract0x7b87…7777
Deployer0x8353…c348
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Giggle Tom 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, 202681High
  2. Sep 3, 202662Medium

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

Related Audits

6 more on the recordAll audits
NVIDIA CorpNVDAB · BNB Chain81HighUnited StablesU · BNB Chain82HighCATBNB Chain82HighVortexPadVPAD · BNB Chain82HighAIOZ NetworkAIOZ · BNB Chain82HighNEAR ProtocolNEAR · BNB Chain82High

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