Is 币恩宝 (BNBO) Safe? Smart Contract Security Analysis

Security Checklist

as of audit · Sep 45 of 7 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityUpgradeable

HoneypotNone found

Buy / sell tax3% / 3%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

34.3%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking29.3%
Walletsanonymous holders, free to sell5.0%
Everyone elsethe rest of the supply65.7%

Effective concentrationwhat the score reads16.7%

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$89.9K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$89.9KShare of depth100.0%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

1 High2 Medium1 Low1 Info

High

Integer Overflow in PackedPoolState Time Fields

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralization Risk due to Immutable Critical Parameters

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

Issue

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

Fix

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

Status

Unresolved

Medium

Denial of Service from External Tax Processor/Dividend Contract

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

Issue

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

Fix

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

Status

Unresolved

Low

Reliance on `block.timestamp` for Critical Logic

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

Issue

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

Fix

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

Status

Unresolved

Info

Lack of Owner Functions for `pools` Management

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

Issue

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

Fix

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

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

Technical8/10Low risk

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

Governance9/10Low risk

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

Upgrades5/10Medium risk

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

Final RecommendationWhat to do about this score

Address the identified integer overflow vulnerability immediately by ensuring proper type handling for time-related calculations.

Implement owner-controlled functions to update critical external contract addresses and economic parameters, or clearly document the upgrade process required for such changes. Thoroughly test the external taxProcessor and dividendContract implementations to ensure their stability and resilience against reverts, as their failure can impact core token functionality.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age7d

Contract0x7fb4…7777

Deployer0x392b…c190

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Badge for your website

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

Sep 4, 202616Low
Sep 3, 20260Low

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

Not Signed In

Is 币恩宝 Safe?

Security Checklist

Holders

Liquidity

Security Findings

Integer Overflow in PackedPoolState Time Fields

Issue

Fix

Status

Centralization Risk due to Immutable Critical Parameters

Issue

Fix

Status

Denial of Service from External Tax Processor/Dividend Contract

Issue

Fix

Status

Reliance on `block.timestamp` for Critical Logic

Issue

Fix

Status

Lack of Owner Functions for `pools` Management

Issue

Fix

Status

Analysis

Contract & Record

Would You Like a More Detailed Audit of 币恩宝?

Is 币恩宝 Safe?

Security Checklist

Holders

Liquidity

Security Findings

Integer Overflow in PackedPoolState Time Fields

Issue

Fix

Status

Centralization Risk due to Immutable Critical Parameters

Issue

Fix

Status

Denial of Service from External Tax Processor/Dividend Contract

Issue

Fix

Status

Reliance on block.timestamp for Critical Logic

Issue

Fix

Status

Lack of Owner Functions for pools Management

Issue

Fix

Status

Analysis

Contract & Record

Related Audits

Would You Like a More Detailed Audit of 币恩宝?

Reliance on `block.timestamp` for Critical Logic

Lack of Owner Functions for `pools` Management