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 →

币恩宝 BNBO
0x7fb4…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, time-based tax and liquidation mechanism. The audit identified a high-severity integer overflow vulnerability in time-related state variable updates, which could lead to incorrect tax expiration logic. Medium-severity issues include centralization risks due to immutable critical parameters and potential denial of service from external contract dependencies. The contract generally follows OpenZeppelin upgradeable patterns and includes a reentrancy guard for tax processing.

1 High2 Medium1 Low1 Informational
Volume 24h
$183.4K
Liquidity
$89.9K
Price
$0.0007743
Token Age
7d
Top 10 Holders
34.3%

Security Findings

1 High2 Med1 Low1 Info
High

Integer Overflow in PackedPoolState Time Fields

H-01The `taxExpirationTime` (uint64) and `antiFarmerExpirationTime` (uint48) fields within the `PackedPoolState` struct are updated by casting a `uint256` sum (e.g., `currentPoolState.taxExpirationTime + block.timestamp` or `block.timestamp + antiFarmerDuration`) directly to the smaller `uint64` or `uint48` types. If the calculated sum exceeds the maximum value representable by the target smaller type, the value will silently truncate, leading to an incorrect and potentially much earlier expiration time than intended. This can prematurely disable tax collection or anti-farmer mechanisms, impacting the contract's economic model.
IssueThe `taxExpirationTime` (uint64) and `antiFarmerExpirationTime` (uint48) fields within the `PackedPoolState` struct are updated by casting a `uint256` sum (e.g., `currentPoolState.taxExpirationTime + block.timestamp` or `block.timestamp + antiFarmerDuration`) directly to the smaller `uint64` or `uint48` types. If the calculated sum exceeds the maximum value representable by the target smaller type, the value will silently truncate, leading to an incorrect and potentially much earlier expiration time than intended. This can prematurely disable tax collection or anti-farmer mechanisms, impacting the contract's economic model.
FixEnsure that the sums `currentPoolState.taxExpirationTime + block.timestamp` and `block.timestamp + antiFarmerDuration` are checked against the maximum values of `uint64` and `uint48` respectively before assignment. If an overflow is possible and undesirable, consider using larger types for these fields (e.g., `uint256`) or implementing explicit overflow checks and handling. For example, `require(sum <= type(uint64).max, "Overflow");` before casting.
StatusUnresolved
Medium

Centralization Risk due to Immutable Critical Parameters

M-01Several critical parameters, including `v2Router`, `taxProcessor`, `dividendContract`, `quoteToken`, `liqExpectedOutputAmount`, `antiFarmerDuration`, `buyTaxRate`, `sellTaxRate`, and the `pools` mapping, are set only during the `initialize` function and cannot be modified by the owner thereafter. This rigidity means that any necessary updates, corrections, or changes to these external dependencies or economic parameters (e.g., if a `taxProcessor` contract needs to be replaced or tax rates adjusted) would necessitate a full contract upgrade. This limits operational flexibility and increases the burden of maintenance.
IssueSeveral critical parameters, including `v2Router`, `taxProcessor`, `dividendContract`, `quoteToken`, `liqExpectedOutputAmount`, `antiFarmerDuration`, `buyTaxRate`, `sellTaxRate`, and the `pools` mapping, are set only during the `initialize` function and cannot be modified by the owner thereafter. This rigidity means that any necessary updates, corrections, or changes to these external dependencies or economic parameters (e.g., if a `taxProcessor` contract needs to be replaced or tax rates adjusted) would necessitate a full contract upgrade. This limits operational flexibility and increases the burden of maintenance.
FixConsider implementing owner-only functions to allow for the safe update of critical external contract addresses and configurable economic parameters (e.g., `setTaxProcessor(address newProcessor)`, `setBuyTaxRate(uint16 newRate)`). These functions should include appropriate input validation and emit events for transparency. For parameters that are intended to be immutable, ensure this is clearly documented and understood.
StatusUnresolved
Medium

Denial of Service from External Tax Processor/Dividend Contract

M-02The `_liquidateTax` function, which is called on every transfer to the `mainPool`, makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. If either of these external contracts contains a bug, is paused, or is maliciously designed to revert, the `_liquidateTax` function will revert. This would consequently cause any transfer to the `mainPool` to fail, leading to a denial of service for a critical part of the token's functionality. While a reentrancy guard is present, it does not prevent reverts from external calls.
IssueThe `_liquidateTax` function, which is called on every transfer to the `mainPool`, makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. If either of these external contracts contains a bug, is paused, or is maliciously designed to revert, the `_liquidateTax` function will revert. This would consequently cause any transfer to the `mainPool` to fail, leading to a denial of service for a critical part of the token's functionality. While a reentrancy guard is present, it does not prevent reverts from external calls.
FixImplement robust error handling for external calls. Consider using a `try/catch` block to gracefully handle reverts from `taxProcessor` and `dividendContract`, allowing the `_liquidateTax` function to complete without reverting the entire transfer. Alternatively, ensure that the external contracts are highly reliable and thoroughly audited. Implement circuit breakers or emergency pause mechanisms for these external interactions if their failure could halt core operations.
StatusUnresolved
Low

Reliance on `block.timestamp` for Critical Logic

L-01The contract heavily relies on `block.timestamp` for managing `taxExpirationTime` and `antiFarmerExpirationTime`, and for triggering state transitions within the `_liquidateTax` function. While `block.timestamp` is commonly used for time-based logic, it is susceptible to manipulation by miners within a certain range (e.g., up to 900 seconds on Ethereum, though typically less on BSC). A malicious miner could slightly adjust the timestamp to accelerate or delay the expiration of tax or anti-farmer periods, potentially impacting trading strategies or arbitrage opportunities.
IssueThe contract heavily relies on `block.timestamp` for managing `taxExpirationTime` and `antiFarmerExpirationTime`, and for triggering state transitions within the `_liquidateTax` function. While `block.timestamp` is commonly used for time-based logic, it is susceptible to manipulation by miners within a certain range (e.g., up to 900 seconds on Ethereum, though typically less on BSC). A malicious miner could slightly adjust the timestamp to accelerate or delay the expiration of tax or anti-farmer periods, potentially impacting trading strategies or arbitrage opportunities.
FixFor critical time-sensitive operations where miner manipulation could have significant financial implications, consider using Chainlink Keepers or similar decentralized oracle solutions for time-based triggers, which provide more robust and tamper-resistant time sources. For less critical operations, `block.timestamp` is generally acceptable, but its limitations should be acknowledged.
StatusUnresolved
Info

Lack of Owner Functions for `pools` Management

I-01The `pools` mapping, which determines which addresses are subject to buy/sell tax in the `TaxEnforcedAntiFarmer` state, is initialized only once during the `initialize` function. There are no owner-controlled functions to add or remove addresses from this mapping after deployment. This design choice makes the list of taxable pools immutable, which might be intended for simplicity or to prevent arbitrary changes. However, it limits operational flexibility, as any future need to update the list of pools would require a contract upgrade.
IssueThe `pools` mapping, which determines which addresses are subject to buy/sell tax in the `TaxEnforcedAntiFarmer` state, is initialized only once during the `initialize` function. There are no owner-controlled functions to add or remove addresses from this mapping after deployment. This design choice makes the list of taxable pools immutable, which might be intended for simplicity or to prevent arbitrary changes. However, it limits operational flexibility, as any future need to update the list of pools would require a contract upgrade.
FixIf the `pools` mapping is intended to be dynamic, consider adding owner-only functions like `addPool(address _pool)` and `removePool(address _pool)` to manage the list. If immutability is the desired design, ensure this is clearly documented and understood by all stakeholders, acknowledging that any changes will necessitate a contract upgrade.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's upgradeable standards (ERC20Upgradeable, OwnableUpgradeable) for robust foundational security (7.2 Code Security). A reentrancy guard is correctly implemented in `_liquidateTax` using `notLiquidating` to prevent reentrant calls during external interactions. However, a high-severity integer overflow exists when updating `taxExpirationTime` and `antiFarmerExpirationTime` due to improper casting of `uint256` sums to smaller `uint64` and `uint48` types (7.2 Code Security). Additionally, the reliance on external `taxProcessor` and `dividendContract` introduces a denial of service risk if these contracts revert (7.6 External).

GovernanceLow9/10

The contract's economic model is driven by a multi-state tax mechanism, with the owner controlling key migration steps via `startMigration` and `finalizeMigration` (7.5 Governance). The `_liquidateTax` function is central to the economic flow, managing tax collection and distribution. A significant economic risk stems from the immutability of critical parameters like `v2Router`, `taxProcessor`, `dividendContract`, and tax rates after initialization (7.4 Economic). This rigidity means any necessary adjustments to the economic model or external dependencies require a full contract upgrade, which can be cumbersome (7.8 Operations).

UpgradesMedium5/10

The contract is designed as an upgradeable proxy, correctly utilizing OpenZeppelin's `Initializable` pattern, including `_disableInitializers()` in the constructor and the `initializer` modifier (7.7 Upgrades). This allows for future logic updates without deploying a new token. However, the lack of owner-controlled functions to update key parameters means that even minor configuration changes would necessitate an upgrade, potentially increasing the frequency and complexity of upgrade operations (7.7 Upgrades).

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

34.3% in top 10
5.0% in wallets29.3% in contracts
Effective Concentration16.7%

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

$89.9K

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
0x392b…c190

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
你们的胆子真是肥嘟嘟的 (肥嘟嘟)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