Quantum Audit Logo
Launch App

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

Is FLORK 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 · 6d old
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance7/10Upgrades8/10Checks passed6 of 7Findings1 Critical · 2 Medium · 2 Low · 1 Info6
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and a multi-state pool system.

Read the full analysis
What raised the score
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 7 days
  • 1 Critical finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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 (6d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
24.8%Contracts72.9%Everyone else
24.8%Contracts72.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
27.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking24.8%
  • Walletsanonymous holders, free to sell2.3%
  • Everyone elsethe rest of the supply72.9%
Effective concentrationwhat the score reads12.2%
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$945.7K across 6 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$591.3KShare of depth62.5%
Top-1 Unlocked Holder14.4%
Top-3 Unlocked35.4%
Unlocked LP held by
0x91a7…3ce40xde93…0bbc0x75be…ee900xa0bf…0efb0xba44…ea330xf74f…34ea0x4860…5fc30xdabb…e22f0xb653…9ef00xe6f6…e0a0

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

Security Findings

1 Critical2 Medium2 Low1 Info
Critical

Critical Logic Error in taxExpirationTime Calculation

The finalizeMigration function incorrectly calculates `currentPoolState.taxExpirationTime = uint64(currentPoolState.taxExpirationTime + block.timestamp);. In initialize, taxExpirationTime is set to uint64(params.taxDuration), meaning it initially holds a duration value. Adding block.timestamp` (an absolute timestamp) to this duration results in an incorrect future timestamp, potentially making the tax active for an unintended and excessively long period, or causing unexpected behavior in tax expiration logic.C-01

Issue

The finalizeMigration function incorrectly calculates `currentPoolState.taxExpirationTime = uint64(currentPoolState.taxExpirationTime + block.timestamp);. In initialize, taxExpirationTime is set to uint64(params.taxDuration), meaning it initially holds a duration value. Adding block.timestamp` (an absolute timestamp) to this duration results in an incorrect future timestamp, potentially making the tax active for an unintended and excessively long period, or causing unexpected behavior in tax expiration logic.

Fix

If taxExpirationTime is intended to be an absolute timestamp, it should be initialized as block.timestamp + params.taxDuration in initialize. In finalizeMigration, if a new duration is to be added, it should be block.timestamp + newDuration or currentPoolState.taxExpirationTime + newDuration (if currentPoolState.taxExpirationTime is already an absolute timestamp). Ensure consistent interpretation of taxExpirationTime as either a duration or an absolute timestamp throughout the c…

Status

Unresolved

Medium

Potential uint48 Overflow for antiFarmerExpirationTime

In finalizeMigration, antiFarmerExpirationTime is set to uint48(block.timestamp + antiFarmerDuration). While block.timestamp is currently within uint48 limits, antiFarmerDuration could be set by the owner to a value large enough that block.timestamp + antiFarmerDuration exceeds type(uint48).max (approximately 2.8e14). If this occurs, the value will silently truncate, leading to an antiFarmerExpirationTime that is significantly earlier than intended, potentially prematurely ending the anti-farmer period.M-01

Issue

In finalizeMigration, antiFarmerExpirationTime is set to uint48(block.timestamp + antiFarmerDuration). While block.timestamp is currently within uint48 limits, antiFarmerDuration could be set by the owner to a value large enough that block.timestamp + antiFarmerDuration exceeds type(uint48).max (approximately 2.8e14). If this occurs, the value will silently truncate, leading to an antiFarmerExpirationTime that is significantly earlier than intended, potentially prematurely ending the anti-farmer period.

Fix

Consider using a larger data type (e.g., uint64 or uint256) for antiFarmerExpirationTime to prevent potential overflow, especially if antiFarmerDuration is expected to be very long. Alternatively, implement a require statement to ensure block.timestamp + antiFarmerDuration does not exceed type(uint48).max before assignment.

Status

Unresolved

Medium

Reentrancy Risk in _liquidateTax (Partial Code)

The _liquidateTax function is called during _transfer. While the poolState is updated *before* potential external calls (implied by the taxProcessor and dividendContract addresses), the full implementation of the _liquidateTax function is truncated. If the truncated portion involves external calls to taxProcessor or dividendContract that transfer funds or can re-enter the token contract, there is a moderate reentrancy risk. An attacker could potentially re-enter the contract and manipulate balanceOf(address(this)) or other state before the external call completes, leading to unexpected behavior or double processing of tax amounts.M-02

Issue

The _liquidateTax function is called during _transfer. While the poolState is updated *before* potential external calls (implied by the taxProcessor and dividendContract addresses), the full implementation of the _liquidateTax function is truncated. If the truncated portion involves external calls to taxProcessor or dividendContract that transfer funds or can re-enter the token contract, there is a moderate reentrancy risk. An attacker could potentially re-enter the contract and manipulate balanceOf(address(this)) or other state before the external call completes, leading to unexpected behavior or double processing of tax amounts.

Fix

Complete the audit of the _liquidateTax function's full implementation, paying close attention to any external calls. Ensure that all state changes related to taxAmount or internal balances are completed *before* any external calls are made. Implement reentrancy guards (e.g., OpenZeppelin's ReentrancyGuard) if external calls are made and critical state is modified after them, or if the external contracts themselves are untrusted.

Status

Unresolved

Low

Centralization Risk with Owner Privileges

The contract utilizes OwnableUpgradeable, granting significant control to a single owner address. The owner can unilaterally initiate and finalize migration states (startMigration, finalizeMigration), which directly impacts the token's tax rates and operational phases. This high degree of centralization means the project's security and integrity heavily depend on the owner's trustworthiness and the security of their private key.L-01

Issue

The contract utilizes OwnableUpgradeable, granting significant control to a single owner address. The owner can unilaterally initiate and finalize migration states (startMigration, finalizeMigration), which directly impacts the token's tax rates and operational phases. This high degree of centralization means the project's security and integrity heavily depend on the owner's trustworthiness and the security of their private key.

Fix

Consider migrating ownership to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and reduce the risk of a single point of failure. For critical operations, implement a time-lock mechanism to allow users to react to pending changes.

Status

Unresolved

Low

Reliance on External Contracts without Robust Checks

The contract relies on external taxProcessor and dividendContract addresses, which are set during initialization. Beyond checking for address(0), there are no further validations (e.g., interface checks, trusted registry checks) to ensure these addresses point to legitimate, non-malicious, or correctly implemented contracts. A compromised or malicious external contract could potentially disrupt the token's tax collection or dividend distribution mechanisms.L-02

Issue

The contract relies on external taxProcessor and dividendContract addresses, which are set during initialization. Beyond checking for address(0), there are no further validations (e.g., interface checks, trusted registry checks) to ensure these addresses point to legitimate, non-malicious, or correctly implemented contracts. A compromised or malicious external contract could potentially disrupt the token's tax collection or dividend distribution mechanisms.

Fix

Implement more robust validation for external contract addresses. Consider adding checks to ensure the addresses implement the expected interfaces (e.g., ITaxProcessor, IDividend). If possible, use a trusted registry or allow only pre-approved addresses to be set. For critical external contracts, consider making them immutable after initialization or requiring a multi-sig for updates.

Status

Unresolved

Info

Inconsistent Use of pools and mainPool for Tax Calculation

The _getTaxWithPoolState function applies tax logic differently based on the PoolState. For PoolState.TaxEnforcedAntiFarmer, it checks pools[from] and pools[to]. However, for PoolState.TaxEnforced, it specifically checks from == mainPool and to == mainPool. This inconsistency, while potentially intentional, could lead to confusion or unexpected tax behavior if the distinction between pools (a mapping of multiple addresses) and mainPool (a single address) is not clearly understood and documented.I-01

Issue

The _getTaxWithPoolState function applies tax logic differently based on the PoolState. For PoolState.TaxEnforcedAntiFarmer, it checks pools[from] and pools[to]. However, for PoolState.TaxEnforced, it specifically checks from == mainPool and to == mainPool. This inconsistency, while potentially intentional, could lead to confusion or unexpected tax behavior if the distinction between pools (a mapping of multiple addresses) and mainPool (a single address) is not clearly understood and documented.

Fix

Clearly document the rationale behind the different tax application logic for PoolState.TaxEnforcedAntiFarmer versus PoolState.TaxEnforced. Ensure that this distinction is well-understood by developers and users to prevent misinterpretations of the token's tax mechanics.

Status

Unresolved

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 a multi-state pool system. The audit identified a critical logic error in the calculation of taxExpirationTime during state transitions, which could lead to unintended tax durations. Other findings include potential integer overflow for antiFarmerExpirationTime, a moderate reentrancy risk in the _liquidateTax function (pending full code review), and significant centralization of control with the contract owner. The contract utilizes OpenZeppelin's upgradeable standards and struct packing for gas efficiency.

Technical8/10Low risk

The contract employs OpenZeppelin's upgradeable ERC20 standards, ensuring a robust foundation (7.1 Architecture). Struct packing is used for PackedPoolState, optimizing gas usage. However, a critical logic error was found in the taxExpirationTime calculation within finalizeMigration, potentially leading to incorrect tax durations (7.2 Code Security). There is also a potential uint48 overflow risk for antiFarmerExpirationTime if a very large duration is set. The _liquidateTax function, while updating poolState before potential external calls, still presents a moderate reentrancy risk depending on the truncated external interactions (7.2 Code Security).

Governance7/10Low risk

The contract's economic model is driven by a dynamic tax mechanism and a multi-state pool system, with maxSupply minted to the owner at initialization (7.4 Economic). The OwnableUpgradeable pattern grants significant control to the contract owner, allowing unilateral changes to tax states via startMigration and finalizeMigration (7.3 Access Control, 7.5 Governance). The contract relies on external taxProcessor and dividendContract addresses, which are set during initialization without robust validation beyond non-zero checks, introducing a dependency risk (7.6 External).

Upgrades8/10Low risk

The contract is designed for upgradeability using OpenZeppelin's Initializable pattern, with _disableInitializers() correctly called in the constructor (7.7 Upgrades). immutable variables are appropriately set in the constructor, ensuring their values persist across upgrades without storage conflicts. Standard upgradeability considerations, such as storage layout compatibility for PackedPoolState, should be maintained in future versions.

Final RecommendationWhat to do about this score

Address the critical logic error in taxExpirationTime calculation immediately to ensure the tax mechanism operates as intended.

Implement robust validation and consider multi-signature control for critical external contract addresses (taxProcessor, dividendContract) to mitigate centralization and dependency risks. Thoroughly review the _liquidateTax function's external interactions once the full code is available to confirm reentrancy safeguards and ensure proper handling of collected taxes.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age6d
Contract0xf405…7777
Deployer0x5138…6ab7
Badge for your website
FLORK security record badge

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
  1. Sep 4, 202626Low

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

Related Audits

6 more on the recordAll audits
LABBNB Chain26LowKoma InuKOMA · BNB Chain26LowZhao Cai Mao招财猫 · BNB Chain26LowYe HiYEHI · BNB Chain26LowThe Final Form BullCZ · BNB Chain25LowBaby AsteroidBABYASTEROID · BNB Chain27Low

Would You Like a More Detailed Audit of FLORK?

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