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.

Early-stage security check — honeypot & rug-pull analysis
Is 施工猫 a Scam?
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 →The audit of FlapTaxTokenV3 identified a critical dependency on an unaudited _processTax function, which is essential for the token's core tax mechanism.
- Proxy contract
- Non-standard proxy storage
- Token age < 7 days
- 1 Critical finding(s) from audit
- 1 High finding(s) from audit
- 1 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)
- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking15.6%
- Walletsanonymous holders, free to sell10.5%
- Everyone elsethe rest of the supply74.0%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x60d1…3eaeNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalMissing Critical External Dependency (_processTax)
The _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.C-01
_processTax)Issue
The _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.
Fix
Provide 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.
Status
Unresolved
HighIncorrect taxExpirationTime Calculation in finalizeMigration
In 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.H-01
taxExpirationTime Calculation in finalizeMigrationIssue
In 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.
Fix
Correct 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.
Status
Unresolved
MediumCentralized Control by Owner
The 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.M-01
Issue
The 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.
Fix
Consider 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.
Status
Unresolved
LowPotential High Gas Costs for _liquidateTax
The _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.L-01
_liquidateTaxIssue
The _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.
Fix
Ensure 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.
Status
Unresolved
InfoUnused State Variables
Several 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.I-01
Issue
Several 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.
Fix
Review 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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).
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).
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).
Prioritize a comprehensive audit of the ITaxProcessor contract and the _processTax function, as it is a critical dependency for the token's core functionality.
Immediately address the taxExpirationTime calculation bug in finalizeMigration to ensure correct tax period enforcement. Consider implementing a multi-signature wallet for owner-controlled functions to mitigate centralization risks and enhance security.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202630Low
- Aug 30, 202612Low
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the SUE contract address?
The 施工猫 (SUE) contract on BNB Chain is 0x2ab8a4dd2191989ac2898006df350b236d2b7777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is 施工猫 a scam?
Quantum Audit's risk score for 施工猫 is 30/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 1%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is SUE liquidity locked?
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $106.8K.
Who holds SUE?
As of Sep 4, 2026, the 10 largest holders own 26.0% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page