Quantum Audit Logo

Is UPONLY a Scam?

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

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

UPONLY UPONLY
0x06f7…7777
BNB Chain
Not verifiedThis 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 9d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and a multi-state machine. It utilizes OpenZeppelin's upgradeable contracts, which is a strong foundation. The audit identified a High-severity integer overflow risk in state transition logic, along with Medium-severity concerns regarding incomplete tax liquidation logic and reliance on specific transfer patterns. Centralization risks due to owner privileges are also noted. The upgradeability pattern is correctly implemented.

1 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$534.2K
Liquidity
$84.3K
Price
$0.0005772
Token Age
3d
Top 10 Holders
43.0%

Security Findings

1 High2 Med1 Low1 Info
High

Integer Overflow/Truncation in `finalizeMigration` Timestamp Calculations

H-01In the `finalizeMigration` function, `currentPoolState.taxExpirationTime` (uint64) and `currentPoolState.antiFarmerExpirationTime` (uint48) are updated by adding `block.timestamp` (uint256) and `antiFarmerDuration` (uint256). If the sum of these values exceeds the maximum capacity of `uint64` or `uint48` respectively, the result will silently truncate, leading to incorrect expiration times. This could cause tax periods or anti-farmer durations to end prematurely or extend indefinitely, disrupting the contract's economic model.
IssueIn the `finalizeMigration` function, `currentPoolState.taxExpirationTime` (uint64) and `currentPoolState.antiFarmerExpirationTime` (uint48) are updated by adding `block.timestamp` (uint256) and `antiFarmerDuration` (uint256). If the sum of these values exceeds the maximum capacity of `uint64` or `uint48` respectively, the result will silently truncate, leading to incorrect expiration times. This could cause tax periods or anti-farmer durations to end prematurely or extend indefinitely, disrupting the contract's economic model.
FixEnsure that timestamp calculations are performed safely. Cast `block.timestamp` and `antiFarmerDuration` to the target `uint` size *before* addition, or use a larger `uint` type for intermediate calculations and then check for overflow before casting back. For example, `uint64(uint256(currentPoolState.taxExpirationTime) + block.timestamp)` with an explicit overflow check, or simply use `uint256` for these variables if their maximum values can exceed `uint64`.
StatusUnresolved
Medium

Incomplete `_liquidateTax` Logic and Unused `notLiquidating` Flag

M-01The `_liquidateTax` function is truncated in the provided source, preventing a full security analysis. However, the `PackedPoolState.notLiquidating` flag is initialized to `true` but is never set to `false` within the visible code. If this flag is intended as a reentrancy guard or to indicate an active liquidation process, its current implementation is incomplete. Without a full view of the function, there's a risk of reentrancy vulnerabilities if external calls are made (e.g., to `taxProcessor` or `dividendContract`) before state updates are finalized or if the flag is not properly managed.
IssueThe `_liquidateTax` function is truncated in the provided source, preventing a full security analysis. However, the `PackedPoolState.notLiquidating` flag is initialized to `true` but is never set to `false` within the visible code. If this flag is intended as a reentrancy guard or to indicate an active liquidation process, its current implementation is incomplete. Without a full view of the function, there's a risk of reentrancy vulnerabilities if external calls are made (e.g., to `taxProcessor` or `dividendContract`) before state updates are finalized or if the flag is not properly managed.
FixProvide the complete `_liquidateTax` function for a thorough review. If `notLiquidating` is intended as a reentrancy guard, implement the Checks-Effects-Interactions pattern: set `notLiquidating` to `false` at the start of the liquidation, perform all state changes, make external calls, and then set `notLiquidating` back to `true`. Ensure all external calls are handled safely, preferably using `SafeERC20` for token transfers and reentrancy guards for arbitrary calls.
StatusUnresolved
Medium

Reliance on `mainPool` Transfers for Tax Liquidation

M-02The `_liquidateTax` function, responsible for processing accumulated tax, is only triggered when a transfer is made *to* the `mainPool` (`to == mainPool`). If transfers to the `mainPool` become infrequent or cease entirely, the accumulated tax (`balanceOf(address(this))`) will not be processed or distributed. This could lead to a large amount of tokens accumulating in the contract, delaying distributions to `taxProcessor` or `dividendContract`, and potentially impacting the protocol's economic stability.
IssueThe `_liquidateTax` function, responsible for processing accumulated tax, is only triggered when a transfer is made *to* the `mainPool` (`to == mainPool`). If transfers to the `mainPool` become infrequent or cease entirely, the accumulated tax (`balanceOf(address(this))`) will not be processed or distributed. This could lead to a large amount of tokens accumulating in the contract, delaying distributions to `taxProcessor` or `dividendContract`, and potentially impacting the protocol's economic stability.
FixImplement a mechanism to allow for manual or scheduled tax liquidation by the owner or a trusted role, independent of transfers to the `mainPool`. Alternatively, consider a more generalized trigger for liquidation, such as a time-based check or a minimum accumulated tax threshold, to ensure timely processing of funds.
StatusUnresolved
Low

Centralization Risk with Owner Privileges

L-01The `owner` role holds significant control over critical contract parameters and state transitions. Functions like `startMigration`, `finalizeMigration`, and the ability to set `taxProcessor` and `dividendContract` addresses are restricted to the owner. While common in early-stage projects, this centralization introduces a single point of failure and relies heavily on the security of the owner's private key. A compromised owner key could lead to unauthorized state changes or redirection of funds.
IssueThe `owner` role holds significant control over critical contract parameters and state transitions. Functions like `startMigration`, `finalizeMigration`, and the ability to set `taxProcessor` and `dividendContract` addresses are restricted to the owner. While common in early-stage projects, this centralization introduces a single point of failure and relies heavily on the security of the owner's private key. A compromised owner key could lead to unauthorized state changes or redirection of funds.
FixConsider implementing a multi-signature wallet for the owner role to distribute control among multiple trusted parties. For highly sensitive operations, explore the use of time-locks to introduce a delay between a decision and its execution, allowing for community review or emergency intervention.
StatusUnresolved
Info

Complex Multi-State Machine

I-01The contract implements a complex multi-state machine (`BondingCurve`, `Migrating`, `TaxEnforcedAntiFarmer`, `TaxEnforced`, `TaxFree`) with various conditions for transitions and tax application. This complexity, while potentially offering flexibility, increases the cognitive load for auditors and developers, making it more challenging to reason about all possible execution paths and potential edge cases. This can lead to subtle logic errors or unexpected behavior in specific state transitions or interactions.
IssueThe contract implements a complex multi-state machine (`BondingCurve`, `Migrating`, `TaxEnforcedAntiFarmer`, `TaxEnforced`, `TaxFree`) with various conditions for transitions and tax application. This complexity, while potentially offering flexibility, increases the cognitive load for auditors and developers, making it more challenging to reason about all possible execution paths and potential edge cases. This can lead to subtle logic errors or unexpected behavior in specific state transitions or interactions.
FixThoroughly document the state machine, including all possible states, transition conditions, and their implications for tax calculation and contract behavior. Consider using formal verification tools or extensive unit testing to ensure all state transitions and their effects are correctly implemented and behave as intended under various scenarios.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's upgradeable ERC20 and access control modules, providing a robust technical foundation (7.1 Architecture, 7.2 Code Security). The tax calculation logic is standard and uses safe arithmetic. However, a High-severity integer overflow/truncation risk exists in the `finalizeMigration` function when updating `taxExpirationTime` and `antiFarmerExpirationTime` (7.2 Code Security). Additionally, the `_liquidateTax` function's logic appears incomplete due to truncation, and the `notLiquidating` flag is unused, raising concerns about potential reentrancy or unhandled states (7.2 Code Security).

GovernanceMedium4/10

The contract implements a complex multi-state machine for tax enforcement and migration, which can be difficult to manage and audit (7.4 Economic). The owner has significant control over state transitions and external contract addresses (`taxProcessor`, `dividendContract`), introducing centralization risk (7.3 Access Control, 7.5 Governance). The tax liquidation mechanism relies on transfers to the `mainPool`, which could lead to accumulated tax not being processed if these transfers are infrequent (7.4 Economic, 7.8 Operations).

UpgradesLow8/10

The contract is designed as an upgradeable proxy implementation using OpenZeppelin's `Initializable` pattern (7.7 Upgrades). The `_disableInitializers()` is correctly called in the constructor, and the `initialize` function uses the `initializer` modifier, ensuring proper setup for proxy deployments. This adherence to best practices for upgradeable contracts minimizes upgrade-related risks.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

43.0% in top 10
23.4% in wallets19.5% in contracts
Effective Concentration31.2%

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

$91.7K across 5 pairs
Pancakeswap v2BNC4analysed$84.3K91.9%Pancakeswap v3USDT$6.7K7.3%Pancakeswap v2金刚$6400.7%UniswapUSDT$860.1%

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
0x47ae…2678
Unlocked LP Held By
0x201a…5614

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

What Raised This Score

8 factors
  • Top-10 concentration > 30% (43.0% total → 31.2% effective; 23.4% in EOAs, 19.5% in contracts — moderate)
  • 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 = 92% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
GUAMedium RiskTrenchesStarterPack (战壕入门包)Medium RiskChainbase Token (C)Medium RiskmemestockMedium RiskGiggle Cat (NIANNIAN)Medium RiskBabySharkMedium Risk

Would You Like a More Detailed Audit of UPONLY?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit