Quantum Audit Logo

Is 施工猫 a Scam?

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

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

施工猫 SUE
0x2ab8…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 5d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of FlapTaxTokenV3 identified a critical dependency on an unaudited `_processTax` function, which is essential for the token's core tax mechanism. A high-severity bug was found in the `taxExpirationTime` calculation during migration, potentially leading to incorrect tax durations. The contract exhibits a medium level of owner centralization for state transitions.

1 Critical1 High1 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
$742.9K
Liquidity
$106.6K
Price
$0.0006347
Token Age
5d
Top 10 Holders
26.0%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Missing Critical External Dependency (`_processTax`)

C-01The `_processTax` function, which is central to the token's tax mechanism and liquidation process, is called internally but its implementation is not provided in the audited code. This function is responsible for handling accumulated tax tokens and is called within a reentrancy-guarded block. Without the full implementation of `_processTax` and the `ITaxProcessor` interface, it is impossible to assess potential reentrancy vulnerabilities, economic exploits, or denial-of-service risks within this critical component.
IssueThe `_processTax` function, which is central to the token's tax mechanism and liquidation process, is called internally but its implementation is not provided in the audited code. This function is responsible for handling accumulated tax tokens and is called within a reentrancy-guarded block. Without the full implementation of `_processTax` and the `ITaxProcessor` interface, it is impossible to assess potential reentrancy vulnerabilities, economic exploits, or denial-of-service risks within this critical component.
FixProvide the complete source code for the `ITaxProcessor` contract and the `_processTax` function for a comprehensive security review. Ensure that `_processTax` adheres to best practices for external calls, including reentrancy guards and gas efficiency.
StatusUnresolved
High

Incorrect `taxExpirationTime` Calculation in `finalizeMigration`

H-01In the `finalizeMigration` function, the `taxExpirationTime` is calculated as `currentPoolState.taxExpirationTime + block.timestamp`. The `currentPoolState.taxExpirationTime` is initially set to `params.taxDuration` in the `initialize` function. This results in the expiration time being `params.taxDuration + block.timestamp` (from epoch) plus the current `block.timestamp`, effectively doubling the current time component. This will lead to an incorrect and significantly longer tax enforcement period than intended.
IssueIn the `finalizeMigration` function, the `taxExpirationTime` is calculated as `currentPoolState.taxExpirationTime + block.timestamp`. The `currentPoolState.taxExpirationTime` is initially set to `params.taxDuration` in the `initialize` function. This results in the expiration time being `params.taxDuration + block.timestamp` (from epoch) plus the current `block.timestamp`, effectively doubling the current time component. This will lead to an incorrect and significantly longer tax enforcement period than intended.
FixCorrect the calculation of `taxExpirationTime` in `finalizeMigration`. It should likely be `uint64(block.timestamp + params.taxDuration)` or `uint64(block.timestamp + antiFarmerDuration)` if `params.taxDuration` is intended as a duration from the point of finalization, similar to how `antiFarmerExpirationTime` is set.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The `startMigration` and `finalizeMigration` functions, which control critical `poolState` transitions and thus the token's tax mechanisms and transfer restrictions, are protected by the `onlyOwner` modifier. This grants a single address (the owner) significant power to unilaterally alter the token's core economic behavior, introducing a single point of failure and a high degree of trust in the owner.
IssueThe `startMigration` and `finalizeMigration` functions, which control critical `poolState` transitions and thus the token's tax mechanisms and transfer restrictions, are protected by the `onlyOwner` modifier. This grants a single address (the owner) significant power to unilaterally alter the token's core economic behavior, introducing a single point of failure and a high degree of trust in the owner.
FixConsider implementing a multi-signature wallet for the contract owner to manage critical functions. Alternatively, introduce a time-lock mechanism or a decentralized governance process for sensitive state transitions to reduce reliance on a single entity.
StatusUnresolved
Low

Potential High Gas Costs for `_liquidateTax`

L-01The `_liquidateTax` function is called on every `_transfer` operation. If the `_processTax` function (whose implementation is unknown) is gas-intensive, or if the accumulated `taxAmount` (balance of `address(this)`) becomes very large, frequent transfers could lead to increased transaction costs or even potential transaction failures if `_processTax` exceeds block gas limits. While a reentrancy guard is in place, gas efficiency remains a concern.
IssueThe `_liquidateTax` function is called on every `_transfer` operation. If the `_processTax` function (whose implementation is unknown) is gas-intensive, or if the accumulated `taxAmount` (balance of `address(this)`) becomes very large, frequent transfers could lead to increased transaction costs or even potential transaction failures if `_processTax` exceeds block gas limits. While a reentrancy guard is in place, gas efficiency remains a concern.
FixEnsure the `_processTax` function is highly optimized for gas efficiency. Consider implementing a mechanism to cap the amount of tax processed in a single call or to allow for manual processing by the owner if automatic liquidation becomes too expensive.
StatusUnresolved
Info

Unused State Variables

I-01Several state variables are initialized in the `initialize` function but are not subsequently used anywhere in the provided contract code. These include `liqExpectedOutputAmount`, `quoteToken`, `dividendContract`, and `initialLiquidationThreshold`. This could indicate incomplete features, dead code, or potential confusion for future development and auditing.
IssueSeveral state variables are initialized in the `initialize` function but are not subsequently used anywhere in the provided contract code. These include `liqExpectedOutputAmount`, `quoteToken`, `dividendContract`, and `initialLiquidationThreshold`. This could indicate incomplete features, dead code, or potential confusion for future development and auditing.
FixReview these unused variables. If they are not intended for future use, remove them to improve code clarity and reduce contract size. If they are part of incomplete features, document their intended purpose and consider their full implementation or removal.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements an upgradeable ERC20 token with a multi-state tax mechanism (7.1 Architecture). It leverages OpenZeppelin's battle-tested libraries for core ERC20 and access control functionalities, enhancing code security (7.2 Code Security). However, a critical portion of the tax processing logic (`_processTax`) is external and unaudited, posing a significant risk (7.2 Code Security). A high-severity bug was identified in the `taxExpirationTime` calculation during migration, leading to incorrect tax durations (7.2 Code Security).

GovernanceLow7/10

The contract design grants the owner significant control over critical state transitions, such as `startMigration` and `finalizeMigration`, which directly impact the token's tax rates and transfer restrictions (7.3 Access Control, 7.5 Governance). This centralization introduces a single point of failure and relies heavily on the owner's trustworthiness. The economic model's stability heavily depends on the external `ITaxProcessor` contract, which is not provided for audit (7.4 Economic, 7.6 External).

UpgradesMedium4/10

The contract correctly utilizes OpenZeppelin's `Initializable` pattern and `_disableInitializers()` in the constructor, ensuring proper upgradeability (7.7 Upgrades). Immutable variables are correctly handled in the constructor, preventing storage collisions during upgrades. The use of a packed struct for `PoolState` is generally safe for upgrades, provided future versions maintain compatible storage layouts (7.7 Upgrades).

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

26.0% in top 10
10.5% in wallets15.6% in contracts
Effective Concentration16.7%

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

$106.8K across 4 pairs
Pancakeswap v2WBNBanalysed$106.6K99.8%UniswapUSDT$2650.2%Uniswap v2USDT$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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

2 addresses
Deployer
0x01bd…7336
Unlocked LP Held By
0x60d1…3eae

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

What Raised This Score

7 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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
AsterMedium RiskMYXMedium RiskBluwhale AI (BLUAI)Medium RiskTaleX (X)Medium RiskPeaqOFT (PEAQ)Medium RiskmubarakMedium Risk

Would You Like a More Detailed Audit of 施工猫?

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

Get Detailed Audit