Quantum Audit Logo

Is FLORK a Scam?

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

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

FLORK FLORK
0xf405…7777
BNB Chain Not verifiedLast checked 2d ago 1 audit on record New Launch · 6d 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 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.

1 Critical2 Medium2 Low1 Informational
! 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.
Volume 24h
$2.59M
Liquidity
$591.3K
Price
$0.02015
Token Age
6d
Top 10 Holders
27.1%

Security Findings

1 Crit2 Med2 Low1 Info
Critical

Critical Logic Error in `taxExpirationTime` Calculation

C-01The `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.
IssueThe `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.
FixIf `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…
StatusUnresolved
Medium

Potential `uint48` Overflow for `antiFarmerExpirationTime`

M-01In `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.
IssueIn `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.
FixConsider 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.
StatusUnresolved
Medium

Reentrancy Risk in `_liquidateTax` (Partial Code)

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

Centralization Risk with Owner Privileges

L-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved
Low

Reliance on External Contracts without Robust Checks

L-02The 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.
IssueThe 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.
FixImplement 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.
StatusUnresolved
Info

Inconsistent Use of `pools` and `mainPool` for Tax Calculation

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

Category Ratings

TechnicalLow8/10

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

GovernanceLow7/10

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

UpgradesLow8/10

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.

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

27.1% in top 10
2.3% in wallets24.8% in contracts
Effective Concentration12.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

$945.7K across 6 pairs
Pancakeswap v2BTCBanalysed$591.3K62.5%Pancakeswap v3USDT$311.4K32.9%Pancakeswap v3USDT$42.6K4.5%Pancakeswap v3牛来$2680.0%Uniswap v2USDT$170.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 Holder14.4%
Top-3 Unlocked35.4%

Key Addresses

11 addresses
Deployer
0x5138…6ab7
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.

What Raised This Score

5 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

Related Audits

6 more on the record
LABMedium RiskKoma Inu (KOMA)Medium RiskThe Final Form Bull (CZ)Medium RiskBaby Asteroid (BABYASTEROID)Medium RiskDecentrawood (DEOD)Medium RiskTest (TST)Medium Risk

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