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

Is SUMMER a Scam?

BNB Chain

Not 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 →

Last checked Sep 4, 2026 · 1 audit on recordNew Launch · 5d old

Chart

64/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance4/10 Upgrades3/10 Checks passed3 of 5 Findings1 Critical · 1 High · 2 Medium · 1 Low · 1 Info6

SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and state-based transfer restrictions.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0%
LP top3 unlocked holders = 100.0%
Token age < 7 days
1 Critical finding(s) from audit
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 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

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.

Security Checklist

as of audit · Sep 43 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockNot locked

UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

27.8%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking23.9%
Walletsanonymous holders, free to sell4.0%
Everyone elsethe rest of the supply72.2%

Effective concentrationwhat the score reads13.5%

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$108.5K across 3 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$108.5KShare of depth100.0%

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Unlocked LP held by

0x5830…7616

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

Security Findings

1 Critical1 High2 Medium1 Low1 Info

Critical

Critical Function Truncation: `_processTax` Missing

The 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.C-01

Issue

Fix

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

Status

Unresolved

High

Centralized Control by Owner

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

Issue

Fix

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

Status

Unresolved

Medium

Complex `_liquidateTax` Logic and State Machine

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

Issue

Fix

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

Status

Unresolved

Medium

Reliance on External Contracts and Untrusted Inputs

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

Issue

Fix

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

Status

Unresolved

Low

Potential for Front-running on `_liquidateTax`

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

Issue

Fix

If _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.

Status

Unresolved

Info

Efficient Storage with `PackedPoolState`

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

Issue

Fix

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

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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.

Governance4/10Medium risk

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

Upgrades3/10High risk

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

Final RecommendationWhat to do about this score

A complete and verifiable source code for all contract components, especially the _processTax function, is essential for a comprehensive security assessment.

Prioritize a thorough review of the _processTax implementation for reentrancy, external call safety, and economic manipulation vectors. Implement robust access control mechanisms, potentially introducing multi-signature governance for critical owner-controlled functions and parameter changes. Conduct comprehensive testing, including fuzzing and formal verification, on the complex state machine and tax liquidation logic to ensure correct and predictable behavior under all conditions.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age5d

Contract0xeeb3…7777

Deployer0xfc38…aec2

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Badge for your website

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History

Sep 4, 202664Medium
Aug 11, 202663Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the SUMMER contract address?

The SUMMER contract on BNB Chain is 0xeeb3d73d4dd44e6e4d957d89492f05d5ccee7777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.