The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms, anti-farmer features, and a state-based lifecycle. The contract utilizes OpenZeppelin's upgradeable standards, ensuring a robust foundation for upgradeability and standard ERC20 functionalities. Key features include a packed struct for gas efficiency and a reentrancy guard for tax processing. However, the audit identified a high-severity integer overflow vulnerability in expiration time calculations, medium-severity concerns regarding the immutability of critical external dependencies and centralized control over state transitions, and a low-severity issue related to gas inefficiency in tax liquidation. Informational findings highlight potential storage collision risks in future upgrades.
Early-stage security check — honeypot & rug-pull analysis
Is utility token a Scam?
BNB ChainNot 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 →The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms, anti-farmer features, and a state-based lifecycle.
Read the full analysis- Proxy contract
- Non-standard proxy storage
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top3 unlocked holders = 87.8%
- Token age < 24h
- 1 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)
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top3 unlocked holders = 87.8% (independent LP — depth risk)
- Token age < 24h (brand new — bot activity, unproven)
- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking24.3%
- Walletsanonymous holders, free to sell3.6%
- Everyone elsethe rest of the supply72.1%
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- Pancakeswap v2GMEBAnalysed$19.93M100.0%
- Pancakeswap v3USDT$4140.0%
- Pancakeswap v2USDT$10.0%
- Uniswap v2USDC$00.0%
- Pancakeswap v2WBNB$00.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xa395…f4570xd379…60d80xb262…eeed0x2ee3…3c7f0xa7ad…829bNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighInteger Overflow in Expiration Time Calculations
The taxExpirationTime (uint64) and antiFarmerExpirationTime (uint48) are updated by adding block.timestamp (uint256) and antiFarmerDuration (uint256) respectively. When the sum exceeds the maximum value of the target smaller type (uint64 or uint48), an integer overflow will occur due to implicit truncation during the cast. This can lead to expiration times being set incorrectly, potentially causing the tax or anti-farmer periods to end prematurely or extend indefinitely, disrupting the contract's economic model.H-01
Issue
The taxExpirationTime (uint64) and antiFarmerExpirationTime (uint48) are updated by adding block.timestamp (uint256) and antiFarmerDuration (uint256) respectively. When the sum exceeds the maximum value of the target smaller type (uint64 or uint48), an integer overflow will occur due to implicit truncation during the cast. This can lead to expiration times being set incorrectly, potentially causing the tax or anti-farmer periods to end prematurely or extend indefinitely, disrupting the contract's economic model.
Fix
Ensure that the sum of currentPoolState.taxExpirationTime + block.timestamp and block.timestamp + antiFarmerDuration does not exceed type(uint64).max and type(uint48).max respectively before casting. Consider using SafeCast from OpenZeppelin or explicitly checking for overflow conditions and reverting if the sum is too large. Alternatively, use a larger data type (e.g., uint256) for these expiration times if their potential values can exceed uint64 or uint48 limits.
Status
Unresolved
MediumImmutability of Critical External Dependencies
The taxProcessor and dividendContract addresses are set only during the initialize function and are not mutable thereafter. These are critical external dependencies for the contract's core functionality (tax processing and dividend distribution). If these external contracts need to be updated (e.g., due to bug fixes, security vulnerabilities, or feature upgrades), the FlapTaxTokenV3 contract itself would require an upgrade. This introduces rigidity and increases the operational complexity and risk associated with updating these components.M-01
Issue
The taxProcessor and dividendContract addresses are set only during the initialize function and are not mutable thereafter. These are critical external dependencies for the contract's core functionality (tax processing and dividend distribution). If these external contracts need to be updated (e.g., due to bug fixes, security vulnerabilities, or feature upgrades), the FlapTaxTokenV3 contract itself would require an upgrade. This introduces rigidity and increases the operational complexity and risk associated with updating these components.
Fix
Implement onlyOwner setter functions for taxProcessor and dividendContract to allow the owner to update these addresses. To mitigate risks associated with immediate changes, consider adding a timelock mechanism to these setter functions, providing a delay before changes take effect and allowing for community review or emergency intervention.
Status
Unresolved
MediumCentralized Control over State Transitions
The startMigration and finalizeMigration functions, which control critical state changes of the token's lifecycle (e.g., transitioning from BondingCurve to Migrating and then to TaxEnforcedAntiFarmer), are protected by the onlyOwner modifier. This grants a single address absolute control over these significant protocol changes. A compromise of the owner's private key could lead to unauthorized or malicious state transitions, potentially disrupting the token's intended economic behavior and user trust.M-02
Issue
The startMigration and finalizeMigration functions, which control critical state changes of the token's lifecycle (e.g., transitioning from BondingCurve to Migrating and then to TaxEnforcedAntiFarmer), are protected by the onlyOwner modifier. This grants a single address absolute control over these significant protocol changes. A compromise of the owner's private key could lead to unauthorized or malicious state transitions, potentially disrupting the token's intended economic behavior and user trust.
Fix
Consider implementing a multi-signature wallet for the contract owner to distribute control among multiple trusted parties. For highly sensitive operations, integrate a timelock mechanism that introduces a delay before state changes take effect, allowing for community oversight and potential emergency cancellation if a malicious or erroneous action is initiated.
Status
Unresolved
LowGas Inefficiency and External Dependency in _liquidateTax
The _liquidateTax function is called on every _transfer operation where the recipient (to) is the mainPool. This function performs several state checks, potentially updates the poolState storage, and makes an external call to _processTax on the taxProcessor contract. Calling this logic, including an external call, on every such transfer can lead to increased gas costs for users interacting with the mainPool and introduces a direct dependency on the taxProcessor's availability and execution cost for basic token transfers.L-01
_liquidateTaxIssue
The _liquidateTax function is called on every _transfer operation where the recipient (to) is the mainPool. This function performs several state checks, potentially updates the poolState storage, and makes an external call to _processTax on the taxProcessor contract. Calling this logic, including an external call, on every such transfer can lead to increased gas costs for users interacting with the mainPool and introduces a direct dependency on the taxProcessor's availability and execution cost for basic token transfers.
Fix
Evaluate the necessity of triggering _liquidateTax on every transfer to the mainPool. Consider alternative mechanisms such as: 1) a periodic liquidation function that can be called by anyone (with incentives) or a trusted keeper, 2) a threshold-based liquidation that only triggers when the collected tax amount reaches a certain level, or 3) batching tax processing to reduce the frequency of external calls.
Status
Unresolved
InfoPotential for Storage Collisions in PackedPoolState (Upgradeability Concern)
The PackedPoolState struct uses tightly packed variables (uint8, uint16, uint96, uint64, uint48) to optimize gas usage. While efficient, modifying the order, size, or adding/removing variables within this struct in a future upgrade can lead to storage collisions if not handled with extreme care and strict adherence to UUPS storage layout rules. Such collisions could corrupt the contract's state, leading to unexpected behavior or loss of funds.I-01
PackedPoolState (Upgradeability Concern)Issue
The PackedPoolState struct uses tightly packed variables (uint8, uint16, uint96, uint64, uint48) to optimize gas usage. While efficient, modifying the order, size, or adding/removing variables within this struct in a future upgrade can lead to storage collisions if not handled with extreme care and strict adherence to UUPS storage layout rules. Such collisions could corrupt the contract's state, leading to unexpected behavior or loss of funds.
Fix
When planning future upgrades, strictly follow the UUPS storage layout guidelines. Any new state variables should always be appended to the end of the contract's storage. Avoid modifying existing structs, especially packed ones, in place. If changes to PackedPoolState are absolutely necessary, consider migrating to a new struct or using a proxy-specific storage slot for new data, ensuring no existing data is overwritten.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The contract leverages OpenZeppelin's upgradeable ERC20 and access control modules, providing a solid architectural foundation (7.1 Architecture). It employs SafeERC20 for external token interactions and includes a reentrancy guard in _liquidateTax for the _processTax call, enhancing code security (7.2 Code Security). However, a high-severity integer overflow vulnerability exists in expiration time calculations, potentially leading to incorrect state transitions. Additionally, the _liquidateTax function, called on every mainPool transfer, introduces gas overhead and an external dependency, impacting operational efficiency (7.8 Operations).
The contract's economic model relies on dynamic tax rates and state transitions managed by the owner (7.4 Economic, 7.5 Governance). The owner has centralized control over critical state changes like startMigration and finalizeMigration, which could be a single point of failure if the owner's key is compromised. Furthermore, critical external dependencies such as taxProcessor and dividendContract are immutable after initialization, limiting flexibility and requiring a full contract upgrade for any address changes (7.6 External).
The contract is designed as an upgradeable implementation using OpenZeppelin's Initializable pattern, with _disableInitializers() correctly called in the constructor (7.7 Upgrades). However, the immutability of taxProcessor and dividendContract means that any updates to these critical external components would necessitate an upgrade of the token contract itself, increasing operational complexity. The use of a tightly packed PackedPoolState struct also introduces a risk of storage collisions in future upgrades if not managed with extreme care, potentially corrupting contract state.
Address the identified integer overflow vulnerability by implementing robust checks or using SafeCast to prevent incorrect expiration time calculations.
Enhance the flexibility and security of critical external dependencies by implementing onlyOwner setter functions, ideally protected by a timelock, to allow for updates without requiring a full contract upgrade. Consider decentralizing control over critical state transitions by implementing a multi-signature wallet for the owner or introducing a timelock for sensitive operations. Evaluate the gas efficiency of the _liquidateTax function and explore alternative, less frequent liquidation mechanisms if feasible.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202640Medium
- Aug 13, 202654Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the UTILITY contract address?
The utility token (UTILITY) contract on BNB Chain is 0xede00776439f9c49c592e43eee34777a51847777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is utility token a scam?
Quantum Audit's risk score for utility token is 40/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is UTILITY liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $19.93M.
Who holds UTILITY?
As of Sep 4, 2026, the 10 largest holders own 27.9% of the supply. The Holders section on this page shows who they are by holder type.
Would You Like a More Detailed Audit of utility token?
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