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 →

比特币社区 比特币社区
0x35f9…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 9d 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 dynamic tax mechanism and a state machine for managing pool states and tax enforcement. The contract utilizes OpenZeppelin's upgradeable standards, ensuring proper initialization and upgrade safety. However, a critical portion of the `_liquidateTax` function, which is central to the token's economic model and state transitions, was truncated in the provided source code, preventing a full security assessment of this core logic. Additionally, the contract exhibits high centralization risk due to extensive owner privileges and relies on external contracts for tax processing and dividends, whose security was not assessed. The complex tax logic and state transitions, while designed for specific tokenomics, introduce potential for unexpected behavior if not managed carefully.

1 Critical1 High1 Medium1 Low
Volume 24h
$114.6K
Liquidity
$76.1K
Price
$0.0004952
Token Age
3mo
Top 10 Holders
47.5%

Security Findings

1 Crit1 High1 Med1 Low
Critical

Truncated `_liquidateTax` Function Prevents Full Audit

C-01The provided source code for the `_liquidateTax` function is truncated. This function is central to the contract's economic model, handling tax collection, state transitions based on `block.timestamp`, and likely interactions with external `ITaxProcessor` and `IDividend` contracts. Without the complete code, it is impossible to fully assess potential vulnerabilities such as reentrancy, incorrect tax calculations, improper state transitions, or issues with external calls.
IssueThe provided source code for the `_liquidateTax` function is truncated. This function is central to the contract's economic model, handling tax collection, state transitions based on `block.timestamp`, and likely interactions with external `ITaxProcessor` and `IDividend` contracts. Without the complete code, it is impossible to fully assess potential vulnerabilities such as reentrancy, incorrect tax calculations, improper state transitions, or issues with external calls.
FixProvide the complete and untruncated source code for the `_liquidateTax` function to allow for a comprehensive security audit. A full review is necessary to identify and mitigate any hidden vulnerabilities.
StatusUnresolved
High

High Centralization Risk via Owner Privileges

H-01The `owner` address has significant control over critical contract functions, including `startMigration` and `finalizeMigration`, which directly change the `PoolState` and impact the token's operational behavior and tax enforcement. Additionally, the entire `maxSupply` is minted to the deployer (who is initially the owner), granting substantial control over initial token distribution. This level of centralization introduces a single point of failure and potential for malicious or compromised owner actions to severely impact the protocol.
IssueThe `owner` address has significant control over critical contract functions, including `startMigration` and `finalizeMigration`, which directly change the `PoolState` and impact the token's operational behavior and tax enforcement. Additionally, the entire `maxSupply` is minted to the deployer (who is initially the owner), granting substantial control over initial token distribution. This level of centralization introduces a single point of failure and potential for malicious or compromised owner actions to severely impact the protocol.
FixConsider implementing a multi-signature wallet for the `owner` role to distribute control and require multiple approvals for critical state-changing operations. For long-term decentralization, explore governance mechanisms to transfer control to a community-driven DAO.
StatusUnresolved
Medium

Reliance on `_transfer` for Time-Sensitive State Transitions

M-01The `_liquidateTax` function, responsible for transitioning `PoolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and collecting taxes based on `block.timestamp`, is only called internally by the `_transfer` function. If there are no token transfers for an extended period, the contract's state might not transition as expected, or accumulated taxes might not be liquidated promptly, potentially leading to outdated tax rates or uncollected funds.
IssueThe `_liquidateTax` function, responsible for transitioning `PoolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and collecting taxes based on `block.timestamp`, is only called internally by the `_transfer` function. If there are no token transfers for an extended period, the contract's state might not transition as expected, or accumulated taxes might not be liquidated promptly, potentially leading to outdated tax rates or uncollected funds.
FixWhile this is a common design pattern, consider if a mechanism for external actors (e.g., a keeper bot or a public function) to trigger `_liquidateTax` or a similar state-transitioning logic is desirable, especially if the protocol's functionality heavily relies on timely state changes. This would ensure the contract remains responsive even during periods of low transfer activity.
StatusUnresolved
Low

Potential `uint` Truncation in `PackedPoolState` Fields

L-01Several fields within the `PackedPoolState` struct, such as `antiFarmerExpirationTime` (uint48), `taxExpirationTime` (uint64), and `liquidationThreshold` (uint96), are explicitly cast from `uint256` values (e.g., `params.antiFarmerDuration`, `params.taxDuration`, `START_LIQ_THRESHOLD`). While `uint48`, `uint64`, and `uint96` are large enough for typical time durations and thresholds, if an exceptionally large `uint256` value were provided during initialization or state updates, it could lead to silent truncation and unexpected behavior. For example, `block.timestamp + antiFarmerDuration` is cast to `uint48`.
IssueSeveral fields within the `PackedPoolState` struct, such as `antiFarmerExpirationTime` (uint48), `taxExpirationTime` (uint64), and `liquidationThreshold` (uint96), are explicitly cast from `uint256` values (e.g., `params.antiFarmerDuration`, `params.taxDuration`, `START_LIQ_THRESHOLD`). While `uint48`, `uint64`, and `uint96` are large enough for typical time durations and thresholds, if an exceptionally large `uint256` value were provided during initialization or state updates, it could lead to silent truncation and unexpected behavior. For example, `block.timestamp + antiFarmerDuration` is cast to `uint48`.
FixImplement explicit `require` checks during initialization and any state-setting functions to ensure that input parameters for `antiFarmerDuration`, `taxDuration`, and `START_LIQ_THRESHOLD` do not exceed the maximum values of their respective `uint48`, `uint64`, and `uint96` types. This adds an extra layer of safety against potential data loss.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable ERC20 and access control components, which is a strong foundation for code security (7.2). The use of `SafeERC20` for external token interactions mitigates common ERC20 pitfalls. However, a critical portion of the `_liquidateTax` function, which handles tax collection and state transitions, was truncated, preventing a complete analysis of its security implications (7.2). The reliance on `_transfer` calls to trigger `_liquidateTax` means state transitions and tax collection are not guaranteed to occur promptly if transaction volume is low (7.8). Additionally, the use of smaller `uint` types for `PackedPoolState` fields like `antiFarmerExpirationTime` and `taxExpirationTime` could lead to truncation if input parameters exceed their maximum capacity, although unlikely in practical scenarios (7.2).

GovernanceLow8/10

The contract's economic model is centered around a dynamic tax system and a multi-stage `PoolState` machine (7.4). The `owner` possesses significant control, including the ability to initiate and finalize migration phases (`startMigration`, `finalizeMigration`), which directly impacts the token's operational state and tax enforcement (7.5). The entire `maxSupply` is minted to the deployer, granting substantial initial control over token distribution (7.4). The system relies on external contracts (`ITaxProcessor`, `IDividend`) for core tax processing and dividend distribution, introducing dependencies on their security and functionality (7.6). The complex interplay of `PoolState` transitions, tax rates, and liquidation thresholds requires careful management to prevent unintended economic consequences.

UpgradesLow9/10

The contract is designed as an upgradeable proxy implementation, correctly utilizing OpenZeppelin's `Initializable` pattern (7.7). The `_disableInitializers()` call in the constructor prevents re-initialization of the implementation contract, and the `initializer` modifier ensures the `initialize` function can only be called once. This adherence to established upgradeability patterns minimizes common upgrade-related risks. The use of `__ERC20_init`, `__ERC20Permit_init`, and `__Ownable_init` within the main `initialize` function is also standard and correct.

Security Checklist

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

Holder Composition

47.5% in top 10
12.6% in wallets35.0% in contracts
Effective Concentration26.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

$76.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 Burned99.8% · ≈ permanent lock
LP Locked99.8% · Null Address

Key Addresses

2 addresses
Deployer
0xde70…df70
Unlocked LP Held By
0x0ed9…9706

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

What Raised This Score

5 factors
  • Top-10 concentration > 20% (47.5% total → 26.6% effective; 12.6% in EOAs, 35.0% in contracts — mild)
  • 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
Build On BNB (BOB)Low Risk你们的胆子真是肥嘟嘟的 (肥嘟嘟)Low Risk币恩宝 (BNBO)Low RiskStonksLow RiskBreak And Reclaim (BAN)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