Quantum Audit Logo

Is utility token a Scam?

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

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

utility token UTILITY
0xede0…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 0h old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (0h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$183.36M
Liquidity
$19.93M
Price
$0.1765
Token Age
0h
Top 10 Holders
27.9%

Security Findings

1 High2 Med1 Low1 Info
High

Integer Overflow in Expiration Time Calculations

H-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Medium

Immutability of Critical External Dependencies

M-01The `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.
IssueThe `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.
FixImplement `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.
StatusUnresolved
Medium

Centralized Control over State Transitions

M-02The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Low

Gas Inefficiency and External Dependency in `_liquidateTax`

L-01The `_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.
IssueThe `_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.
FixEvaluate 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.
StatusUnresolved
Info

Potential for Storage Collisions in `PackedPoolState` (Upgradeability Concern)

I-01The `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.
IssueThe `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.
FixWhen 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceMedium5/10

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

UpgradesMedium4/10

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.

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

27.9% in top 10
3.6% in wallets24.3% in contracts
Effective Concentration13.3%

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

$19.93M across 6 pairs
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 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 Holder44.8%
Top-3 Unlocked87.8%

Key Addresses

6 addresses
Deployer
0xe279…c2b9
Unlocked LP Held By
0xa395…f4570xd379…60d80xb262…eeed0x2ee3…3c7f0xa7ad…829b

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

What Raised This Score

8 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

Related Audits

6 more on the record
APRO oracle Token (AT)Medium RiskArk Of Panda (AOP)Medium RiskHOMER CZ (HOMER)Medium RiskBaby Doge Coin (BABYDOGE)Medium RiskBitway Token (BTW)Medium RiskMarsCoinMedium Risk

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