Quantum Audit Logo

Is Zhao Cai Mao Safe?

On-chain security analysis — is it a scam or legit?

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

Zhao Cai Mao 招财猫
0x975f…7777
BNB Chain
Not verifiedThis 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 today 1 audit on record
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 multiple operational states. It leverages OpenZeppelin's upgradeable contracts for a robust foundation. However, a critical portion of the `_liquidateTax` function, central to the token's economic logic, is truncated in the provided source code, preventing a full security assessment. The contract also exhibits centralized control by the owner and relies on external contracts for tax processing and dividends, introducing additional risks.

1 High2 Medium1 Low2 Informational
Volume 24h
$332.8K
Liquidity
$135.1K
Price
$0.001885
Token Age
17d
Top 10 Holders
21.6%

Security Findings

1 High2 Med1 Low2 Info
High

Incomplete `_liquidateTax` Function Logic

H-01The provided source code for the `_liquidateTax` function is truncated, specifically the critical part that handles the actual liquidation of collected tax and potentially further state transitions based on `liquidationThreshold`. This prevents a full security assessment of the token's core economic mechanism, which could harbor unknown vulnerabilities related to fund handling, state transitions, or external interactions.
IssueThe provided source code for the `_liquidateTax` function is truncated, specifically the critical part that handles the actual liquidation of collected tax and potentially further state transitions based on `liquidationThreshold`. This prevents a full security assessment of the token's core economic mechanism, which could harbor unknown vulnerabilities related to fund handling, state transitions, or external interactions.
FixProvide the complete and verified source code for the `_liquidateTax` function to enable a comprehensive and accurate security audit of this critical component.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The `OwnableUpgradeable` pattern grants significant control to the contract owner. Functions such as `startMigration` and `finalizeMigration` allow the owner to unilaterally change the contract's `PoolState`, which directly impacts tax rates and transfer restrictions. This introduces a single point of failure and a high trust assumption on the owner, who could potentially manipulate the system or be compromised.
IssueThe `OwnableUpgradeable` pattern grants significant control to the contract owner. Functions such as `startMigration` and `finalizeMigration` allow the owner to unilaterally change the contract's `PoolState`, which directly impacts tax rates and transfer restrictions. This introduces a single point of failure and a high trust assumption on the owner, who could potentially manipulate the system or be compromised.
FixConsider implementing a multi-signature wallet for ownership or a time-locked governance mechanism for critical operations to reduce centralization risk and enhance security. For less critical functions, a role-based access control (RBAC) system could be explored.
StatusUnresolved
Medium

External Contract Dependencies (TaxProcessor, DividendContract)

M-02The contract relies on external `taxProcessor` and `dividendContract` addresses, which are set during initialization. The `_liquidateTax` function (implied by its name and context) likely interacts with these contracts to process collected taxes and distribute dividends. The security and integrity of these external contracts are paramount to the overall system's safety. A vulnerability or malicious behavior in `taxProcessor` or `dividendContract` could compromise funds or disrupt the token's functionality.
IssueThe contract relies on external `taxProcessor` and `dividendContract` addresses, which are set during initialization. The `_liquidateTax` function (implied by its name and context) likely interacts with these contracts to process collected taxes and distribute dividends. The security and integrity of these external contracts are paramount to the overall system's safety. A vulnerability or malicious behavior in `taxProcessor` or `dividendContract` could compromise funds or disrupt the token's functionality.
FixConduct thorough security audits of the `taxProcessor` and `dividendContract` implementations. Implement robust input validation and consider re-entrancy guards if external calls are made from `_liquidateTax` to these contracts, especially if they handle significant value.
StatusUnresolved
Low

Potential for Front-Running State Transitions

L-01The `_liquidateTax` function modifies the `poolState` based on `block.timestamp` (e.g., `taxExpirationTime`, `antiFarmerExpirationTime`). Since `_liquidateTax` is called on every `_transfer`, users can observe pending state changes in the mempool. An attacker could front-run transactions to execute transfers under a more favorable tax regime (e.g., before taxes are enforced or after they expire) or to avoid restrictions, potentially leading to minor economic imbalances.
IssueThe `_liquidateTax` function modifies the `poolState` based on `block.timestamp` (e.g., `taxExpirationTime`, `antiFarmerExpirationTime`). Since `_liquidateTax` is called on every `_transfer`, users can observe pending state changes in the mempool. An attacker could front-run transactions to execute transfers under a more favorable tax regime (e.g., before taxes are enforced or after they expire) or to avoid restrictions, potentially leading to minor economic imbalances.
FixWhile inherent to time-based logic on public blockchains, consider if the impact of front-running on state transitions is acceptable. For critical state changes, a more robust, multi-step, or time-locked process might be considered, though this adds complexity and may not be necessary given the current design.
StatusUnresolved
Info

Immutable Variables in Upgradeable Contract Constructor

I-01The `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable` and initialized in the constructor. In an upgradeable contract using the UUPS pattern, constructor logic is executed only once when the proxy contract is deployed, not when the implementation is deployed or upgraded. This means these `immutable` variables are correctly stored in the proxy's storage, ensuring they persist across upgrades.
IssueThe `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable` and initialized in the constructor. In an upgradeable contract using the UUPS pattern, constructor logic is executed only once when the proxy contract is deployed, not when the implementation is deployed or upgraded. This means these `immutable` variables are correctly stored in the proxy's storage, ensuring they persist across upgrades.
FixNo action required. This is a good practice for defining constants that should not change across upgrades in an upgradeable contract.
StatusResolved
Info

Packed Storage for `PackedPoolState`

I-02The `PackedPoolState` struct uses tightly packed data types (`uint8`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`) to optimize storage usage. This reduces the number of storage slots required, leading to lower gas costs for reading and writing these state variables, which is a good practice for gas efficiency.
IssueThe `PackedPoolState` struct uses tightly packed data types (`uint8`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`) to optimize storage usage. This reduces the number of storage slots required, leading to lower gas costs for reading and writing these state variables, which is a good practice for gas efficiency.
FixNo action required. This is a good practice for gas optimization and efficient state management.
StatusResolved

Category Ratings

TechnicalLow9/10

The contract utilizes OpenZeppelin's upgradeable standards, including `Initializable`, `ERC20Upgradeable`, `ERC20PermitUpgradeable`, and `OwnableUpgradeable`, demonstrating a solid foundation for upgradeability and token functionality (7.1 Architecture). Gas optimization is evident through the use of `PackedPoolState` for efficient storage (7.2 Code Security). However, a critical portion of the `_liquidateTax` function is truncated, preventing a full assessment of its security and potential technical vulnerabilities (7.2 Code Security).

GovernanceMedium6/10

The token implements a dynamic tax mechanism with various `PoolState`s and time-based transitions, managed by the contract owner. This centralized control allows the owner to initiate migration phases and influence tax enforcement (7.3 Access Control). The system relies on external `taxProcessor` and `dividendContract` for tax handling, introducing significant external dependency risk (7.6 External). The economic implications of the tax rates and liquidation thresholds, particularly the unverified `_liquidateTax` logic, cannot be fully assessed (7.4 Economic).

UpgradesLow9/10

The contract correctly uses OpenZeppelin's UUPS proxy pattern, inheriting `Initializable` and calling `_disableInitializers` in the constructor, along with the `initializer` modifier for `initialize`. Immutable variables `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` are correctly handled in the constructor, ensuring they are stored in the proxy's storage and persist across upgrades. This setup provides a robust and standard upgradeability framework (7.7 Upgrades).

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

21.6% in top 10
6.6% in wallets15.0% in contracts
Effective Concentration12.6%

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

$135.1K

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x93ca…65b0
Unlocked LP Held By
0x26a4…ef23

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

What Raised This Score

7 factors
  • 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 < 30 days (still settling)
  • 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

Related Audits

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

Would You Like a More Detailed Audit of Zhao Cai Mao?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit