Quantum Audit Logo
Launch App

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

Is PIZZA Safe?

BNB 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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance5/10Upgrades4/10Checks passed3 of 5Findings2 High · 1 Medium · 1 Low · 2 Info6
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and multiple pool states.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 2 High finding(s) from audit
  • 1 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)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 93% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 93% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 2 High finding(s) from audit
  • 1 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
24.3%Contracts8.0%Wallets67.7%Everyone else
24.3%Contracts8.0%67.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
32.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking24.3%
  • Walletsanonymous holders, free to sell8.0%
  • Everyone elsethe rest of the supply67.7%
Effective concentrationwhat the score reads17.7%
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$70.3K across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$65.3KShare of depth92.8%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xf949…0298

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

Security Findings

2 High1 Medium1 Low2 Info
High

Incorrect taxExpirationTime Initialization Logic

The taxExpirationTime field in PackedPoolState is initialized with uint64(params.taxDuration) in the initialize function. Subsequently, in finalizeMigration, it is updated by adding block.timestamp to its current value (currentPoolState.taxExpirationTime + block.timestamp). This implies params.taxDuration is treated as an absolute timestamp during initialization and then as a duration during migration finalization. This inconsistent logic will result in an incorrect taxExpirationTime that is significantly longer than intended, leading to prolonged tax enforcement.H-01

Issue

The taxExpirationTime field in PackedPoolState is initialized with uint64(params.taxDuration) in the initialize function. Subsequently, in finalizeMigration, it is updated by adding block.timestamp to its current value (currentPoolState.taxExpirationTime + block.timestamp). This implies params.taxDuration is treated as an absolute timestamp during initialization and then as a duration during migration finalization. This inconsistent logic will result in an incorrect taxExpirationTime that is significantly longer than intended, leading to prolonged tax enforcement.

Fix

Ensure consistent interpretation of params.taxDuration. If params.taxDuration is intended as a duration, taxExpirationTime should be initialized as uint64(block.timestamp + params.taxDuration) in the initialize function. The finalizeMigration function should then only update the state and antiFarmerExpirationTime as needed, or recalculate taxExpirationTime based on block.timestamp and the intended duration.

Status

Unresolved

High

Owner Centralization and Immutability of Critical Parameters

The owner has significant centralized control over the token's core mechanics through startMigration and finalizeMigration, which dictate the PoolState and tax enforcement. Furthermore, several critical external contract addresses (taxProcessor, v2Router, quoteToken, mainPool, dividendContract) and parameters (antiFarmerDuration, liqExpectedOutputAmount) are set only during initialization and lack direct setter functions. This immutability creates a high operational risk, as these dependencies cannot be updated or replaced without a full contract upgrade if they become compromised, deprecated, or require changes.H-02

Issue

The owner has significant centralized control over the token's core mechanics through startMigration and finalizeMigration, which dictate the PoolState and tax enforcement. Furthermore, several critical external contract addresses (taxProcessor, v2Router, quoteToken, mainPool, dividendContract) and parameters (antiFarmerDuration, liqExpectedOutputAmount) are set only during initialization and lack direct setter functions. This immutability creates a high operational risk, as these dependencies cannot be updated or replaced without a full contract upgrade if they become compromised, deprecated, or require changes.

Fix

Consider implementing onlyOwner (or multi-signature) protected setter functions for critical external contract addresses and configurable parameters. This would allow for greater flexibility and responsiveness to changes in the ecosystem or security incidents without requiring a full contract upgrade. Clearly document the owner's responsibilities and the implications of these centralized controls.

Status

Unresolved

Medium

Potential Truncation in PackedPoolState Fields

The liquidationThreshold field within the PackedPoolState struct is defined as uint96, while the initial values MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD are uint256. If START_LIQ_THRESHOLD (or any value assigned to liquidationThreshold) exceeds the maximum value of uint96 (2^96 - 1), it will be truncated. This could lead to a smaller effective liquidation threshold than intended, potentially affecting the tax liquidation mechanism and economic stability.M-01

Issue

The liquidationThreshold field within the PackedPoolState struct is defined as uint96, while the initial values MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD are uint256. If START_LIQ_THRESHOLD (or any value assigned to liquidationThreshold) exceeds the maximum value of uint96 (2^96 - 1), it will be truncated. This could lead to a smaller effective liquidation threshold than intended, potentially affecting the tax liquidation mechanism and economic stability.

Fix

Ensure that START_LIQ_THRESHOLD and MIN_LIQ_THRESHOLD are within the bounds of uint96 or explicitly cast them with a require check to prevent truncation. Alternatively, consider increasing the size of liquidationThreshold to uint256 if the intended values can exceed uint96 max, though this would increase storage costs.

Status

Unresolved

Low

Reliance on External ITaxProcessor Contract

The _processTax function makes an external call to the taxProcessor contract to handle collected tax funds. While a reentrancy guard (notLiquidating) is in place for this specific call, the overall security and correctness of the FlapTaxTokenV3 contract are highly dependent on the implementation and trustworthiness of the ITaxProcessor contract. A bug, vulnerability, or malicious logic within ITaxProcessor could lead to the loss or misuse of collected tax funds.L-01

Issue

The _processTax function makes an external call to the taxProcessor contract to handle collected tax funds. While a reentrancy guard (notLiquidating) is in place for this specific call, the overall security and correctness of the FlapTaxTokenV3 contract are highly dependent on the implementation and trustworthiness of the ITaxProcessor contract. A bug, vulnerability, or malicious logic within ITaxProcessor could lead to the loss or misuse of collected tax funds.

Fix

Thoroughly audit the ITaxProcessor contract to ensure its security and intended functionality. Implement robust monitoring for the taxProcessor address and its behavior. Consider adding mechanisms for the owner to pause tax processing or update the taxProcessor address in emergencies (as suggested in H-02).

Status

Unresolved

Info

Lack of Event Emission for Critical Parameter Initialization

Several critical parameters, including v2Router, quoteToken, antiFarmerDuration, mainPool, liqExpectedOutputAmount, taxProcessor, and dividendContract, are set during the initialize function but no corresponding events are emitted. While these parameters are immutable after initialization, emitting events for their initial values would significantly improve transparency and allow off-chain monitoring systems to track the contract's configuration from deployment.I-01

Issue

Several critical parameters, including v2Router, quoteToken, antiFarmerDuration, mainPool, liqExpectedOutputAmount, taxProcessor, and dividendContract, are set during the initialize function but no corresponding events are emitted. While these parameters are immutable after initialization, emitting events for their initial values would significantly improve transparency and allow off-chain monitoring systems to track the contract's configuration from deployment.

Fix

Emit events for all critical parameters set during the initialize function. For example, `event ConfigUpdated(address indexed v2Router, address indexed taxProcessor, uint256 antiFarmerDuration, ...);`.

Status

Unresolved

Info

Unused State Variables

The state variables dividendContract, v2Router, quoteToken, and liqExpectedOutputAmount are declared and initialized in the contract but are not used in any of the provided functions. This might indicate incomplete functionality, placeholder variables for future development, or an oversight.I-02

Issue

The state variables dividendContract, v2Router, quoteToken, and liqExpectedOutputAmount are declared and initialized in the contract but are not used in any of the provided functions. This might indicate incomplete functionality, placeholder variables for future development, or an oversight.

Fix

Review the purpose of these unused variables. If they are intended for future functionality, consider adding comments to clarify their role. If they are no longer needed, remove them to reduce contract size and improve clarity.

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 and multiple pool states. It leverages OpenZeppelin's upgradeable contracts for security and maintainability. The audit identified a critical logic error in tax expiration time calculation, significant owner centralization, and potential truncation issues in packed storage. While reentrancy guards are present for tax processing, the reliance on external contracts and the immutability of critical parameters pose operational risks. Recommendations focus on correcting the logic, enhancing decentralization, and improving transparency.

Technical7/10Low risk

7.1 Architecture: The contract utilizes a well-structured upgradeable ERC20 pattern from OpenZeppelin, which is a strong foundation. The PackedPoolState struct is an efficient design choice for storage. 7.2 Code Security: A reentrancy guard (notLiquidating) is correctly implemented around the external call to _processTax. However, a critical logic error exists in the calculation of taxExpirationTime during initialization and migration, leading to incorrect tax durations. 7.3 Access Control: The _transfer function correctly implements state-dependent restrictions. However, the owner has significant control over state transitions (startMigration, finalizeMigration) which directly impact the token's tax mechanics.

Governance5/10Medium risk

7.4 Economic: The token implements a flexible tax system with different pool states and anti-farmer durations. The maxSupply is minted to the initializer, establishing initial distribution. However, the liquidationThreshold field in PackedPoolState (uint96) could lead to truncation if START_LIQ_THRESHOLD (uint256) is excessively large, potentially impacting the tax liquidation mechanism. 7.5 Governance: The owner has centralized control over critical state changes, such as starting and finalizing migration, which directly affects the token's tax enforcement. Several critical external contract addresses and parameters are immutable after initialization, increasing operational risk if these dependencies need updates or become compromised. 7.6 External: The contract relies heavily on the ITaxProcessor contract for handling collected taxes. The security and correctness of this external dependency are paramount to the overall system's integrity.

Upgrades4/10Medium risk

7.7 Upgrades: The contract correctly uses OpenZeppelin's Initializable pattern, enabling secure upgrades. This allows for future enhancements and bug fixes without redeploying the entire system. However, any future upgrades must carefully manage the storage layout, especially for the PackedPoolState struct, to avoid storage collisions or data corruption. The contract does not explicitly define a UUPS proxy pattern, but uses the base Initializable contract.

Final RecommendationWhat to do about this score

Address the critical logic error in taxExpirationTime calculation to ensure correct tax durations.

Implement direct setter functions for critical external contract addresses and parameters, guarded by onlyOwner or a multi-signature wallet, to enhance operational flexibility and reduce the need for full contract upgrades in case of dependency changes or compromises. Carefully review the sizing of liquidationThreshold within PackedPoolState to prevent potential truncation issues with large uint256 values.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age18d
Contract0x8554…7777
Deployer0xec6f…2458
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
PIZZA 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, 202651Medium
  2. Aug 20, 202620Low

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

Related Audits

6 more on the recordAll audits
Baby AnsemBABYANSEM · BNB Chain51MediumEVAABNB Chain51MediumBubblemapsBMT · BNB Chain51MediumDGrid AIDGAI · BNB Chain51MediumStupid Kid傻孩子 · BNB Chain51MediumCycle Network TokenCYC · BNB Chain51Medium

Would You Like a More Detailed Audit of PIZZA?

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