Is PIZZA Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Low2 Info

High

Incorrect `taxExpirationTime` Initialization Logic

H-01The `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.

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

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

StatusUnresolved

High

Owner Centralization and Immutability of Critical Parameters

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

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

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

StatusUnresolved

Medium

Potential Truncation in `PackedPoolState` Fields

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

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

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

StatusUnresolved

Low

Reliance on External `ITaxProcessor` Contract

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

IssueThe `_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.

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

StatusUnresolved

Info

Lack of Event Emission for Critical Parameter Initialization

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

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

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

StatusUnresolved

Info

Unused State Variables

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceMedium5/10

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.

UpgradesMedium4/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

32.3% in top 10

8.0% in wallets24.3% in contracts

Effective Concentration17.7%

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

$70.3K across 5 pairs

Pancakeswap v2BTCBanalysed$65.3K UniswapUSDT$5.0K Pancakeswap v3USDT$25

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

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0xec6f…2458

Unlocked LP Held By

0xf949…0298

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

What Raised This Score

9 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

Is PIZZA Safe?

Security Findings

Incorrect `taxExpirationTime` Initialization Logic

Owner Centralization and Immutability of Critical Parameters

Potential Truncation in `PackedPoolState` Fields

Reliance on External `ITaxProcessor` Contract

Lack of Event Emission for Critical Parameter Initialization

Unused State Variables

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of PIZZA?