Quantum Audit Logo
Launch App

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

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

肥嘟嘟BNB Chain
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance9/10Upgrades5/10Checks passed5 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex tax mechanism and a multi-state machine.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 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 < 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax1% / 1%

Holders

as of audit · Sep 4, 2026
12.7%Contracts2.7%84.6%Everyone else
12.7%84.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
15.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.7%
  • Walletsanonymous holders, free to sell2.7%
  • Everyone elsethe rest of the supply84.6%
Effective concentrationwhat the score reads7.8%
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 4$106.1K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$106.1KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 High2 Medium1 Low1 Info
High

Critical External Dependency and Single Point of Failure

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Immutability of Key External Addresses

Several 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Denial of Service Risk from External Call Revert

The _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.M-02

Issue

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

Fix

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

Status

Unresolved

Low

Potential for uint48 Overflow in antiFarmerExpirationTime

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Complex State Machine and Logic

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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

Governance9/10Low risk

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

Upgrades5/10Medium risk

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

Final RecommendationWhat to do about this score

It is strongly recommended to implement an owner-controlled mechanism to update critical external contract addresses, especially for the taxProcessor, v2Router, quoteToken, and dividendContract.

This would mitigate the single point of failure and enhance operational flexibility without requiring a full contract upgrade for dependency changes. Additionally, consider implementing robust error handling or a circuit breaker mechanism for the _processTax external call to prevent a complete denial of service for token transfers if the taxProcessor reverts.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age7d
Contract0x03c5…7777
Deployer0x73eb…70f4
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
你们的胆子真是肥嘟嘟的 security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202616Low
  2. Aug 30, 20260Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the 肥嘟嘟 contract address?

The 你们的胆子真是肥嘟嘟的 (肥嘟嘟) contract on BNB Chain is 0x03c59bbf8ba49ce79831403b86acbc40d3167777. 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 16/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: 1% / 1%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is 肥嘟嘟 liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $106.1K.

Who holds 肥嘟嘟?

As of Sep 4, 2026, the 10 largest holders own 15.4% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
币恩宝BNBO · BNB Chain16LowStonksBNB Chain16LowBuild On BNBBOB · BNB Chain15LowDBURNBNB Chain17Low比特币社区BNB Chain15LowThe ChampCoinTCC · BNB Chain17Low

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 Is this your token? Publish your own audit on this page