Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Binance Cat a Scam?

BNBCATBNB 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 · 1 Medium · 2 Low · 1 Info5
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a liquidation process for collected taxes.

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

Our automated scanner reviewed Binance Cat (BNBCAT) on BNB Chain. 5 of 7 security checks passed — see the full breakdown below.

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
9.7%Contracts7.9%Wallets82.3%Everyone else
9.7%7.9%82.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
17.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking9.7%
  • Walletsanonymous holders, free to sell7.9%
  • Everyone elsethe rest of the supply82.3%
Effective concentrationwhat the score reads11.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$223.0K across 4 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$217.7KShare of depth97.6%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9% · Null Address
Unlocked LP held by
0x3083…f0080x0ed9…9706

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

Security Findings

1 High1 Medium2 Low1 Info
High

External Call to Untrusted ITaxProcessor (Truncated Code)

The _liquidateTax function, which is called on every token transfer, makes an external call to _processTax via the ITaxProcessor interface. The implementation of _processTax and the ITaxProcessor contract itself are not provided for audit. While a notLiquidating flag is used as a reentrancy guard for the liquidation process, the external call to an unaudited contract introduces a significant security risk. A malicious or vulnerable ITaxProcessor could exploit the FlapTaxTokenV3 contract, potentially leading to unauthorized fund transfers, state manipulation, or denial of service.H-01

Issue

The _liquidateTax function, which is called on every token transfer, makes an external call to _processTax via the ITaxProcessor interface. The implementation of _processTax and the ITaxProcessor contract itself are not provided for audit. While a notLiquidating flag is used as a reentrancy guard for the liquidation process, the external call to an unaudited contract introduces a significant security risk. A malicious or vulnerable ITaxProcessor could exploit the FlapTaxTokenV3 contract, potentially leading to unauthorized fund transfers, state manipulation, or denial of service.

Fix

Conduct a thorough security audit of the ITaxProcessor and IDividend contracts. Ensure they adhere to secure coding practices, implement necessary reentrancy guards, and handle funds and state transitions securely. Consider implementing a timelock for critical changes to external contract addresses.

Status

Unresolved

Medium

Incomplete State Reversion on _processTax Failure

In the _liquidateTax function, the notLiquidating flag is set to false before the external call to _processTax. If the _processTax call reverts for any reason (e.g., due to an issue in the taxProcessor or dividendContract), the notLiquidating flag will remain false. This would permanently prevent any future liquidations from occurring, effectively bricking the tax collection mechanism and requiring a contract upgrade to resolve.M-01

Issue

In the _liquidateTax function, the notLiquidating flag is set to false before the external call to _processTax. If the _processTax call reverts for any reason (e.g., due to an issue in the taxProcessor or dividendContract), the notLiquidating flag will remain false. This would permanently prevent any future liquidations from occurring, effectively bricking the tax collection mechanism and requiring a contract upgrade to resolve.

Fix

Ensure that the notLiquidating flag is reset to true even if _processTax reverts. This can be achieved by wrapping the external call in a try-catch block or by ensuring the flag is reset in a finally block if Solidity supported it. A simpler approach is to reset the flag immediately after the external call, and if the external call reverts, the entire transaction would revert, thus reverting the flag change as well. However, if the intent is to allow the transaction to continue while ma…

Status

Unresolved

Low

Unused initialLiquidationThreshold Variable

The initialLiquidationThreshold state variable is set during the initialize function but is never read or used anywhere else in the provided contract code. This variable represents dead code.L-01

Issue

The initialLiquidationThreshold state variable is set during the initialize function but is never read or used anywhere else in the provided contract code. This variable represents dead code.

Fix

Remove the initialLiquidationThreshold state variable to reduce contract size, save gas on deployment, and improve code clarity. If it is intended for future use, ensure it is properly documented and integrated into the contract's logic.

Status

Unresolved

Low

Potential Truncation for liquidationThreshold

The MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD are defined as uint256, but poolState.liquidationThreshold is a uint96. In the initialize function, poolState.liquidationThreshold is set by casting START_LIQ_THRESHOLD to uint96. While START_LIQ_THRESHOLD is likely to be within the uint96 range, if a value exceeding 2^96 - 1 were ever passed, it would be truncated without warning, potentially leading to unexpected behavior or a lower-than-intended liquidation threshold.L-02

Issue

The MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD are defined as uint256, but poolState.liquidationThreshold is a uint96. In the initialize function, poolState.liquidationThreshold is set by casting START_LIQ_THRESHOLD to uint96. While START_LIQ_THRESHOLD is likely to be within the uint96 range, if a value exceeding 2^96 - 1 were ever passed, it would be truncated without warning, potentially leading to unexpected behavior or a lower-than-intended liquidation threshold.

Fix

Ensure that START_LIQ_THRESHOLD and MIN_LIQ_THRESHOLD are explicitly constrained to fit within uint96 during initialization or parameter setting. Alternatively, consider making poolState.liquidationThreshold a uint256 for consistency and to avoid potential truncation issues.

Status

Unresolved

Info

Centralization Risk with Owner Privileges

The owner address has significant control over critical contract functions, including startMigration, finalizeMigration, and setting key external contract addresses (v2Router, taxProcessor, dividendContract, pools) during initialization. This centralization introduces a single point of failure, as a compromised owner key could lead to malicious state changes, manipulation of tax parameters, or redirection of funds.I-01

Issue

The owner address has significant control over critical contract functions, including startMigration, finalizeMigration, and setting key external contract addresses (v2Router, taxProcessor, dividendContract, pools) during initialization. This centralization introduces a single point of failure, as a compromised owner key could lead to malicious state changes, manipulation of tax parameters, or redirection of funds.

Fix

Consider implementing a multi-signature wallet for the owner address to distribute control and reduce the risk associated with a single point of failure. For highly sensitive operations, a timelock mechanism could be introduced to provide a delay before changes take effect, allowing for community review or emergency intervention.

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 dynamic tax mechanisms and a liquidation process for collected taxes. It leverages OpenZeppelin's upgradeable contracts for a solid foundation. While a reentrancy guard is present for the liquidation process, a critical external call to an unaudited ITaxProcessor within a frequently executed function introduces significant risk. Additionally, a failure in this external call could permanently disable the liquidation mechanism. The contract exhibits a high degree of owner centralization for critical operations and parameter changes.

Technical8/10Low risk

The contract utilizes OpenZeppelin's upgradeable standards for ERC20 and Ownable, providing a robust foundation (7.1). A reentrancy guard (notLiquidating flag) is implemented for the tax liquidation process, which is a positive security measure (7.2). However, a critical external call to an untrusted ITaxProcessor contract within the frequently executed _liquidateTax function poses a significant risk, as its full implementation is not available for audit (7.6). Additionally, if _processTax reverts, the notLiquidating flag remains false, permanently disabling future liquidations (7.2).

Governance9/10Low risk

The contract's economic parameters, such as buy/sell tax rates and liquidation thresholds, are well-defined and managed through a multi-state pool system (7.4). The owner has significant control over critical state transitions, including migration phases and setting key external contract addresses (7.3, 7.5). This centralization introduces a single point of failure and requires trust in the owner's operational security (7.8).

Upgrades5/10Medium risk

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's Initializable and Upgradeable contracts, ensuring future upgradeability (7.7). The _disableInitializers() call in the constructor prevents re-initialization attacks on the implementation contract. All critical state-changing functions related to migration are protected by the onlyOwner modifier, ensuring controlled upgrades (7.3).

Final RecommendationWhat to do about this score

Prioritize a comprehensive security audit of all external contracts interacting with FlapTaxTokenV3, especially ITaxProcessor and IDividend, to mitigate risks associated with external calls.

Implement robust error handling for external calls to prevent critical contract functionality from being permanently disabled. Consider implementing multi-signature control for owner-privileged functions to reduce centralization risk.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age7d
Contract0x3efb…7777
Deployer0x2419…83d5
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Binance Cat 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, 202613Low
  2. Aug 30, 20260Low

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

Related Audits

6 more on the recordAll audits
FrippyBNB Chain13LowGiggle MascotMAX · BNB Chain13LowOKZOOAIOT · BNB Chain13LowNianNianBNB Chain13LowARIA.AIARIA · BNB Chain12LowBreak And ReclaimBAN · BNB Chain14Low

Would You Like a More Detailed Audit of Binance Cat?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page