Quantum Audit Logo

Is SUMMER a Scam?

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

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

SUMMER SUMMER
0xeeb3…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 5d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and state-based transfer restrictions. The audit identified a critical vulnerability due to the truncation of the `_processTax` function, preventing a full security assessment of its implications, particularly regarding reentrancy and economic manipulation. Additionally, significant centralized control by the owner and complex internal logic present further risks.

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

Security Findings

1 Crit1 High2 Med1 Low1 Info
Critical

Critical Function Truncation: `_processTax` Missing

C-01The provided source code for the `FlapTaxTokenV3` contract is truncated, specifically omitting the implementation of the `_processTax` function. This function is called within `_liquidateTax`, which is triggered by every `_transfer` operation. Without the full code, it is impossible to assess critical security risks such as reentrancy vulnerabilities, potential for denial-of-service, economic manipulation (e.g., through AMM interactions), or unintended external calls. This represents a severe gap in the audit coverage.
IssueThe provided source code for the `FlapTaxTokenV3` contract is truncated, specifically omitting the implementation of the `_processTax` function. This function is called within `_liquidateTax`, which is triggered by every `_transfer` operation. Without the full code, it is impossible to assess critical security risks such as reentrancy vulnerabilities, potential for denial-of-service, economic manipulation (e.g., through AMM interactions), or unintended external calls. This represents a severe gap in the audit coverage.
FixProvide the complete and verifiable source code for the `_processTax` function and any other missing components. A full audit of this critical function is required to identify and mitigate potential vulnerabilities before deployment or continued operation.
StatusUnresolved
High

Centralized Control by Owner

H-01The contract grants significant control to the `owner` address. Functions like `startMigration` and `finalizeMigration` which control the `PoolState` transitions are `onlyOwner`. Additionally, critical external contract addresses such as `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`, and `liqExpectedOutputAmount` are set during initialization and can potentially be changed by the owner (if setter functions exist, or through an upgrade). This centralization introduces a single point of failure and trust, where a compromised owner key could lead to severe consequences, including manipulation of the token's economic model or redirection of funds.
IssueThe contract grants significant control to the `owner` address. Functions like `startMigration` and `finalizeMigration` which control the `PoolState` transitions are `onlyOwner`. Additionally, critical external contract addresses such as `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`, and `liqExpectedOutputAmount` are set during initialization and can potentially be changed by the owner (if setter functions exist, or through an upgrade). This centralization introduces a single point of failure and trust, where a compromised owner key could lead to severe consequences, including manipulation of the token's economic model or redirection of funds.
FixConsider implementing a multi-signature wallet for ownership to distribute control and reduce the risk of a single point of compromise. For highly sensitive operations or parameter changes, introduce a time-lock mechanism to allow community review or provide a window for intervention before changes take effect.
StatusUnresolved
Medium

Complex `_liquidateTax` Logic and State Machine

M-01The `_liquidateTax` function contains complex conditional logic involving `PoolState` transitions, `block.timestamp` comparisons for `taxExpirationTime` and `antiFarmerExpirationTime`, and checks against `liquidationThreshold`. This intricate logic, combined with internal state modifications and external calls (via `_processTax`), increases the likelihood of subtle bugs, race conditions, or unexpected behavior, especially under specific timing conditions or edge cases in the `PoolState` transitions. The function also modifies `notLiquidating` state twice within the same execution path, which could be simplified.
IssueThe `_liquidateTax` function contains complex conditional logic involving `PoolState` transitions, `block.timestamp` comparisons for `taxExpirationTime` and `antiFarmerExpirationTime`, and checks against `liquidationThreshold`. This intricate logic, combined with internal state modifications and external calls (via `_processTax`), increases the likelihood of subtle bugs, race conditions, or unexpected behavior, especially under specific timing conditions or edge cases in the `PoolState` transitions. The function also modifies `notLiquidating` state twice within the same execution path, which could be simplified.
FixRefactor the `_liquidateTax` function to simplify its logic where possible. Implement comprehensive unit and integration tests covering all possible `PoolState` transitions, time-based conditions, and `liquidationThreshold` scenarios. Consider using formal verification tools to prove the correctness of the state machine transitions and ensure no unintended states or behaviors can occur.
StatusUnresolved
Medium

Reliance on External Contracts and Untrusted Inputs

M-02The `FlapTaxTokenV3` contract relies heavily on several external contracts, including `taxProcessor`, `dividendContract`, `v2Router`, and `quoteToken`. The security and integrity of these external dependencies are critical to the overall security of the token. A vulnerability or malicious behavior in any of these external contracts could directly impact `FlapTaxTokenV3`, potentially leading to fund loss, incorrect tax calculations, or system disruption. The `_processTax` function (truncated) likely interacts with these, making their trustworthiness paramount.
IssueThe `FlapTaxTokenV3` contract relies heavily on several external contracts, including `taxProcessor`, `dividendContract`, `v2Router`, and `quoteToken`. The security and integrity of these external dependencies are critical to the overall security of the token. A vulnerability or malicious behavior in any of these external contracts could directly impact `FlapTaxTokenV3`, potentially leading to fund loss, incorrect tax calculations, or system disruption. The `_processTax` function (truncated) likely interacts with these, making their trustworthiness paramount.
FixThoroughly audit all external contracts that `FlapTaxTokenV3` interacts with. Implement robust input validation for all addresses and parameters set by the owner. Consider using a 'circuit breaker' mechanism or upgradeability to quickly pause or update the contract in case a critical vulnerability is discovered in an external dependency.
StatusUnresolved
Low

Potential for Front-running on `_liquidateTax`

L-01The `_liquidateTax` function is called internally by `_transfer`, meaning any user initiating a token transfer can trigger its execution. If the `_processTax` function (which is truncated) involves sensitive operations like AMM swaps (e.g., selling collected tax for `quoteToken`), it could be susceptible to front-running or sandwich attacks. A malicious actor could observe a pending transaction that triggers `_liquidateTax`, then execute their own transactions before and after to manipulate prices and profit at the expense of the protocol or users.
IssueThe `_liquidateTax` function is called internally by `_transfer`, meaning any user initiating a token transfer can trigger its execution. If the `_processTax` function (which is truncated) involves sensitive operations like AMM swaps (e.g., selling collected tax for `quoteToken`), it could be susceptible to front-running or sandwich attacks. A malicious actor could observe a pending transaction that triggers `_liquidateTax`, then execute their own transactions before and after to manipulate prices and profit at the expense of the protocol or users.
FixIf `_processTax` involves AMM swaps, consider implementing mechanisms to mitigate front-running, such as using commit-reveal schemes, limiting the amount processed in a single transaction, or introducing a minimum slippage parameter for swaps. Alternatively, consider making tax liquidation an explicit, permissioned function rather than implicitly triggered by every transfer.
StatusUnresolved
Info

Efficient Storage with `PackedPoolState`

I-01The contract utilizes a `PackedPoolState` struct with tightly packed `uint` types (`uint8`, `uint16`, `uint96`, `uint64`, `uint48`). This approach is a good practice for optimizing storage slots and reducing gas costs associated with state variable access and modification. It demonstrates an awareness of EVM storage layout and gas efficiency.
IssueThe contract utilizes a `PackedPoolState` struct with tightly packed `uint` types (`uint8`, `uint16`, `uint96`, `uint64`, `uint48`). This approach is a good practice for optimizing storage slots and reducing gas costs associated with state variable access and modification. It demonstrates an awareness of EVM storage layout and gas efficiency.
FixContinue to apply storage optimization techniques where appropriate, ensuring that type casting and bitwise operations (if any) are handled carefully to prevent truncation or overflow issues. Document the packing strategy clearly for future maintainers.
StatusResolved

Category Ratings

TechnicalMedium6/10

The contract utilizes OpenZeppelin's upgradeable standards for ERC20 and access control, which is a strong foundation (7.1 Architecture). The `PackedPoolState` struct demonstrates an effort towards storage optimization. However, the critical truncation of the `_processTax` function within the provided source code prevents a thorough assessment of reentrancy, denial of service, and other code security aspects (7.2 Code Security). The complex state machine and conditional logic within `_liquidateTax` also increase the potential for subtle bugs.

GovernanceMedium4/10

The contract exhibits a high degree of centralized control, with the `onlyOwner` modifier governing critical state transitions like `startMigration` and `finalizeMigration` (7.3 Access Control, 7.5 Governance). The owner also sets crucial external dependencies such as `taxProcessor`, `dividendContract`, and `v2Router`, which introduces significant trust assumptions (7.6 External). The economic parameters, including tax rates and liquidation thresholds, are dynamically managed, but the full economic implications cannot be assessed without the `_processTax` implementation (7.4 Economic).

UpgradesHigh3/10

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's `Initializable` and `Upgradeable` contracts. The `_disableInitializers()` in the constructor and the `initializer` modifier are used appropriately, preventing re-initialization attacks. No immediate upgrade safety issues were identified within the provided code (7.7 Upgrades).

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.8% in top 10
4.0% in wallets23.9% in contracts
Effective Concentration13.5%

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

$108.5K across 3 pairs
Pancakeswap v2SPYBanalysed$108.5K100.0%Pancakeswap v2WBNB$130.0%Uniswap v2USDT$10.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xfc38…aec2
Unlocked LP Held By
0x5830…7616

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

What Raised This Score

10 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 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
Pro Token (PRO)High RiskElonCoinHigh RiskSomniaOFT (SOMI)High RiskGoPlus Security (GPS)High RiskAsteroid Shiba (ASTEROID)High RiskCaldera (ERA)High Risk

Would You Like a More Detailed Audit of SUMMER?

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

Get Detailed Audit