Quantum Audit Logo

Is Binance Cat a Scam?

Honeypot, rug-pull and ownership checks

Is this your token? Publish your own audit on this page →

Binance Cat BNBCAT
0x3efb…7777
BNB Chain Not verifiedLast checked 2d 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 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.

1 High1 Medium2 Low1 Informational
i Our automated scanner reviewed Binance Cat (BNBCAT) on BNB Chain. 4 of 5 security checks passed — see the full breakdown below.
Volume 24h
$1.27M
Liquidity
$217.7K
Price
$0.002749
Age
7d
Top 10 Holders
17.7%

Security Findings

1 High1 Med2 Low1 Info
High

External Call to Untrusted `ITaxProcessor` (Truncated Code)

H-01The `_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.
IssueThe `_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.
FixConduct 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.
StatusUnresolved
Medium

Incomplete State Reversion on `_processTax` Failure

M-01In 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.
IssueIn 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.
FixEnsure 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…
StatusUnresolved
Low

Unused `initialLiquidationThreshold` Variable

L-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved
Low

Potential Truncation for `liquidationThreshold`

L-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Info

Centralization Risk with Owner Privileges

I-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow9/10

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

UpgradesMedium5/10

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

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

17.7% in top 10
7.9% in wallets9.7% in contracts
Effective Concentration11.8%

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

$223.0K across 4 pairs
Pancakeswap v2WBNBanalysed$217.7K97.6%Pancakeswap v3USDT$5.2K2.3%Uniswap v2USDT$1220.1%

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.9% · ≈ permanent lock
LP Locked99.9% · Null Address

Key Addresses

3 addresses
Deployer
0x2419…83d5
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.

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
  • 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

Related Audits

6 more on the record
FrippyLow RiskGiggle Mascot (MAX)Low RiskOKZOO (AIOT)Low RiskNianNianLow RiskARIA.AI (ARIA)Low RiskBuild On BNB (BOB)Low Risk

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