Quantum Audit Logo

Is 你们的胆子真是肥嘟嘟的 Safe?

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

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

你们的胆子真是肥嘟嘟的 肥嘟嘟
0x03c5…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex tax mechanism and a multi-state machine. The audit identified a High-severity risk related to the critical external dependency on the `taxProcessor` contract, which can lead to a denial of service for token transfers. Medium-severity issues include the immutability of other key external addresses and the direct DoS risk from `_processTax` reverts. The contract utilizes OpenZeppelin's upgradeable standards and incorporates reentrancy guards for its tax liquidation logic, demonstrating good security practices in some areas.

1 High2 Medium1 Low1 Informational
Volume 24h
$172.5K
Liquidity
$106.1K
Price
$0.0008376
Token Age
7d
Top 10 Holders
15.4%

Security Findings

1 High2 Med1 Low1 Info
High

Critical External Dependency and Single Point of Failure

H-01The `taxProcessor` contract is a critical external dependency, responsible for processing collected taxes and potentially adjusting the `liquidationThreshold`. It is set during initialization and cannot be changed. This introduces a significant centralization risk and a single point of failure. If the `taxProcessor` contract is compromised, becomes malicious, or is unfunctional, it can halt all token transfers (via `_processTax` reverting) or manipulate key economic parameters, leading to a denial of service or economic exploit.
IssueThe `taxProcessor` contract is a critical external dependency, responsible for processing collected taxes and potentially adjusting the `liquidationThreshold`. It is set during initialization and cannot be changed. This introduces a significant centralization risk and a single point of failure. If the `taxProcessor` contract is compromised, becomes malicious, or is unfunctional, it can halt all token transfers (via `_processTax` reverting) or manipulate key economic parameters, leading to a denial of service or economic exploit.
FixImplement an owner-controlled function to update the `taxProcessor` address. This function should include a timelock and/or a multi-signature approval process to provide a window for review and prevent immediate malicious changes. Ensure the new `taxProcessor` contract is thoroughly audited.
StatusUnresolved
Medium

Immutability of Key External Addresses

M-01Several critical external contract addresses (`v2Router`, `quoteToken`, `taxProcessor`, `dividendContract`) are set only during initialization and lack setter functions. This makes them effectively immutable. Should any of these dependencies require an update (e.g., due to an upgrade, security vulnerability, or market changes), the entire `FlapTaxTokenV3` contract would need to undergo a full upgrade, which is a more complex and costly operation compared to simply updating an address via an owner-controlled setter.
IssueSeveral critical external contract addresses (`v2Router`, `quoteToken`, `taxProcessor`, `dividendContract`) are set only during initialization and lack setter functions. This makes them effectively immutable. Should any of these dependencies require an update (e.g., due to an upgrade, security vulnerability, or market changes), the entire `FlapTaxTokenV3` contract would need to undergo a full upgrade, which is a more complex and costly operation compared to simply updating an address via an owner-controlled setter.
FixIntroduce owner-controlled setter functions for `v2Router`, `quoteToken`, and `dividendContract`. These setters should include appropriate access control (e.g., `onlyOwner`) and potentially a timelock for critical addresses to allow for community review or emergency response.
StatusUnresolved
Medium

Denial of Service Risk from External Call Revert

M-02The `_liquidateTax` function, which is invoked during every `_transfer` operation, makes an external call to `taxProcessor.processTax()`. If this external call reverts for any reason (e.g., `taxProcessor` is paused, drained, or encounters an internal error), it will cause the entire `_transfer` transaction to revert. This creates a denial of service vulnerability for all token transfers, effectively freezing the token's utility.
IssueThe `_liquidateTax` function, which is invoked during every `_transfer` operation, makes an external call to `taxProcessor.processTax()`. If this external call reverts for any reason (e.g., `taxProcessor` is paused, drained, or encounters an internal error), it will cause the entire `_transfer` transaction to revert. This creates a denial of service vulnerability for all token transfers, effectively freezing the token's utility.
FixConsider implementing a circuit breaker or a fallback mechanism for the `_processTax` call. For example, if `_processTax` reverts, the contract could temporarily disable tax processing or allow transfers to proceed without tax, while alerting the owner. Alternatively, ensure the `taxProcessor` contract is extremely robust and cannot be easily bricked or made to revert.
StatusUnresolved
Low

Potential for `uint48` Overflow in `antiFarmerExpirationTime`

L-01The `antiFarmerExpirationTime` variable is stored as a `uint48`. While `block.timestamp` is currently far from exceeding the maximum value of `uint48` (approximately 2.8 x 10^14, which corresponds to roughly 89,000 years from the Unix epoch), in extremely long-lived contracts, this could theoretically lead to an overflow. Although a very low risk for typical contract lifespans, it's a consideration for extreme longevity.
IssueThe `antiFarmerExpirationTime` variable is stored as a `uint48`. While `block.timestamp` is currently far from exceeding the maximum value of `uint48` (approximately 2.8 x 10^14, which corresponds to roughly 89,000 years from the Unix epoch), in extremely long-lived contracts, this could theoretically lead to an overflow. Although a very low risk for typical contract lifespans, it's a consideration for extreme longevity.
FixFor maximum future-proofing, consider using `uint64` for `antiFarmerExpirationTime` to align with `taxExpirationTime` and provide a significantly longer safe operating period. Alternatively, document this limitation and its implications for the contract's expected lifespan.
StatusUnresolved
Info

Complex State Machine and Logic

I-01The contract implements a multi-state machine (`PoolState`) with several transitions and conditional logic within the `_transfer` and `_liquidateTax` functions. While designed to manage different phases of the token, this complexity increases the surface area for potential logic errors or unexpected behavior, particularly during state transitions. Comprehensive testing of all state paths is crucial to ensure correct operation.
IssueThe contract implements a multi-state machine (`PoolState`) with several transitions and conditional logic within the `_transfer` and `_liquidateTax` functions. While designed to manage different phases of the token, this complexity increases the surface area for potential logic errors or unexpected behavior, particularly during state transitions. Comprehensive testing of all state paths is crucial to ensure correct operation.
FixEnsure comprehensive unit and integration tests cover all possible state transitions and edge cases within the `_transfer` and `_liquidateTax` functions. Consider formal verification for the state machine logic to mathematically prove its correctness and prevent unintended behavior.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's upgradeable ERC20 standard, providing a solid foundation (7.2 Code Security). A reentrancy guard is implemented around the `_processTax` call within `_liquidateTax`, which is a good practice (7.2 Code Security). However, a significant technical risk stems from the `taxProcessor` contract being a critical, unchangeable external dependency, posing a single point of failure and potential denial of service for all token transfers if it reverts (7.6 External, 7.2 Code Security). The immutability of other key external addresses also limits operational flexibility (7.8 Operations).

GovernanceLow9/10

The contract's economic model relies heavily on the `taxProcessor` for tax collection and liquidation threshold adjustments, centralizing significant control (7.4 Economic). Owner-controlled functions for state migration (`startMigration`, `finalizeMigration`) provide necessary administrative oversight (7.5 Governance). However, the complex multi-state machine and the critical, unchangeable dependency on `taxProcessor` introduce potential for economic manipulation or disruption if the `taxProcessor` is compromised or misconfigured (7.4 Economic, 7.1 Architecture).

UpgradesMedium5/10

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's `Initializable` and `Upgradeable` contracts, including `_disableInitializers()` in the constructor and proper `__init` calls (7.7 Upgrades). This provides a robust and secure upgrade mechanism. A minor concern is that the immutability of key external addresses means any changes to these dependencies would necessitate a full contract upgrade, rather than a simpler address update (7.7 Upgrades, 7.8 Operations).

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

15.4% in top 10
2.7% in wallets12.7% in contracts
Effective Concentration7.8%

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

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

Key Addresses

1 addresses
Deployer
0x73eb…70f4

What Raised This Score

6 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • 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
币恩宝 (BNBO)Low RiskBuild On BNB (BOB)Low RiskDBURNLow RiskBEMLow RiskCZ Terminal Token (CZT)Low RiskFrippyLow Risk

Would You Like a More Detailed Audit of 你们的胆子真是肥嘟嘟的?

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

Get Detailed Audit