Honeypot, rug-pull and ownership checks

Is Bicat a Scam?

BICAT

BNB 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

55/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical7/10 Governance5/10 Upgrades4/10 Checks passed5 of 7 Findings2 High · 2 Medium · 1 Low · 1 Info6

SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and pool state transitions.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 92.8%
LP top3 unlocked holders = 100.0%
Token age < 30 days
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 92.8% (independent LP — depth risk, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
Token age < 30 days (still settling)
2 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

Our automated scanner reviewed Bicat (BICAT) 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 lockNot locked

UpgradeabilityUpgradeable

HoneypotNone found

Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

25.3%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking20.1%
Walletsanonymous holders, free to sell5.3%
Everyone elsethe rest of the supply74.7%

Effective concentrationwhat the score reads13.3%

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$69.7K across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$68.8KShare of depth98.7%

Top-1 Unlocked Holder92.8%

Top-3 Unlocked100.0%

Unlocked LP held by

0x966d…e41a0xfebe…384c0x5ad1…2cb00x0642…e5c1

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

Security Findings

2 High2 Medium1 Low1 Info

High

Integer Overflow in `finalizeMigration` State Updates

In the finalizeMigration function, the taxExpirationTime and antiFarmerExpirationTime are updated by adding block.timestamp (and antiFarmerDuration) and then casting the result to uint64 and uint48 respectively. Since block.timestamp is a uint256, the sum is performed in uint256 arithmetic. If this sum exceeds the maximum value of uint64 or uint48, the explicit cast will truncate the higher bits, leading to an integer overflow and an incorrect, potentially much smaller, expiration time. This could prematurely expire tax enforcement or anti-farmer measures, disrupting the protocol's economic model.H-01

Issue

Fix

Before performing the addition and cast, implement a check to ensure the sum does not exceed the maximum value of the target type (type(uint64).max or type(uint48).max). If an overflow is detected, revert the transaction or implement a robust strategy to handle such large timestamp values, potentially by using larger integer types for these expiration times if feasible.

Status

Unresolved

High

Centralized Control Over Critical State Transitions

The startMigration and finalizeMigration functions, which are responsible for transitioning the contract's PoolState (e.g., from BondingCurve to Migrating and then to TaxEnforcedAntiFarmer), are protected by the onlyOwner modifier. This grants a single address (the contract owner) complete and immediate control over the activation and deactivation of core tax mechanisms and anti-farmer measures. This high degree of centralization introduces a significant single point of failure and trust, as a compromised or malicious owner could manipulate the protocol's economic behavior without external checks.H-02

Issue

Fix

To mitigate this centralization risk, consider implementing a multi-signature wallet for the owner address. Alternatively, introduce a time-lock mechanism for these critical state transition functions, allowing a grace period for community review or intervention. For long-term decentralization, explore transitioning to a community-governed voting mechanism for such sensitive operations.

Status

Unresolved

Medium

Inflexibility of Key Economic Parameters

Several critical economic parameters, including buyTaxRate, sellTaxRate, taxProcessor address, dividendContract address, and initialLiquidationThreshold (which sets liquidationThreshold in PackedPoolState), are set exclusively during the initialize function and lack owner-controlled functions for subsequent modification. This inflexibility means that if market conditions change, or if the external taxProcessor or dividendContract addresses need to be updated (e.g., due to a bug, upgrade, or change in strategy), the entire contract would require an upgrade. This is a more complex, costly, and risky operation than simply updating a parameter.M-01

Issue

Fix

Implement owner-controlled functions (e.g., setTaxRates, setTaxProcessor, setDividendContract, setLiquidationThreshold) to allow for the adjustment of these critical parameters. These functions should be protected by appropriate access controls (e.g., onlyOwner or multi-sig) and could benefit from time-locks to provide transparency and prevent immediate malicious changes.

Status

Unresolved

Medium

Potential Flash Loan Manipulation of Liquidation Timing

The _liquidateTax function's execution, specifically the processing of accumulated tax, is triggered when balanceOf(address(this)) exceeds currentPoolState.liquidationThreshold (or if the state becomes TaxFree). A malicious actor could potentially use a flash loan to temporarily inflate the contract's token balance by sending a large amount of tokens to the contract address just before a transaction that triggers _liquidateTax. This could force a premature liquidation, or conversely, prevent a liquidation if the balance is manipulated below the threshold, potentially disrupting the intended tax processing schedule and economic model.M-02

Issue

Fix

Re-evaluate the liquidationThreshold mechanism. Consider alternative triggers for tax processing that are less susceptible to temporary balance manipulations, such as a time-weighted average balance or a fixed time interval. Ensure the taxProcessor contract is robust against unexpected or frequent calls and that its economic model can withstand potential timing manipulations.

Status

Unresolved

Low

Complex `_transfer` Logic

The _transfer function contains multiple nested if/else if statements that dictate behavior based on the PoolState enum. This complex branching logic, while functional, can make the code harder to read, reason about, and audit. Increased complexity inherently raises the likelihood of subtle bugs or unintended interactions between different states, especially during future modifications or upgrades.L-01

Issue

Fix

Consider refactoring the _transfer function to reduce its complexity. This could involve adopting a more explicit state machine pattern or breaking down the logic into smaller, more focused internal functions, each responsible for handling a specific PoolState. Comprehensive unit and integration testing, particularly covering all possible state transitions and edge cases, is crucial.

Status

Unresolved

Info

Immutable Thresholds Limit Future Flexibility

The MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD variables are declared as immutable. While this design choice ensures their values cannot be changed after deployment, it also means that if these initial parameters prove suboptimal or require adjustment in the future due to evolving market conditions or protocol needs, a full contract upgrade or redeployment would be necessary. This limits the protocol's adaptability without a more significant operational overhead.I-01

Issue

Fix

This is a design decision. If long-term flexibility for these parameters is desired, they should be made mutable and controlled by the owner or a governance mechanism. If immutability is the intended design, ensure the initial values are thoroughly vetted and understood to be suitable for the protocol's entire lifecycle.

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 pool state transitions. It leverages OpenZeppelin's upgradeable standards and includes a reentrancy guard for tax liquidation. However, the audit identified several high-severity issues, including an integer overflow vulnerability in state update logic and significant centralization risks due to owner-controlled critical functions. Additionally, key economic parameters are inflexible, requiring contract upgrades for adjustments, and the complex transfer logic increases the potential for subtle bugs. These findings collectively contribute to a 'High' overall risk level.

Technical7/10Low risk

The contract utilizes OpenZeppelin's upgradeable ERC20, Ownable, and Permit standards, which enhances code security (7.2 Code Security). The PackedPoolState struct is efficiently designed for gas optimization. However, a high-severity integer overflow vulnerability exists in the finalizeMigration function when updating taxExpirationTime and antiFarmerExpirationTime (7.2 Code Security). The _transfer function's complex branching logic across different PoolStates increases the risk of subtle bugs (7.2 Code Security). While a reentrancy guard is correctly implemented for the _liquidateTax function, the mechanism for triggering liquidation based on contract balance could be susceptible to flash loan manipulation (7.4 Economic).

Governance5/10Medium risk

The protocol exhibits high centralization, as the owner has exclusive control over critical state transitions via startMigration and finalizeMigration functions (7.3 Access Control, 7.5 Governance). This allows a single entity to dictate tax enforcement and anti-farmer measures. Furthermore, key economic parameters such as buyTaxRate, sellTaxRate, taxProcessor, dividendContract addresses, and liquidationThreshold are set during initialization and cannot be modified without a contract upgrade (7.4 Economic). This inflexibility limits the protocol's adaptability to changing market conditions or operational needs.

Upgrades4/10Medium risk

The contract correctly implements the OpenZeppelin upgradeable pattern, including Initializable and _disableInitializers() in the constructor, ensuring proper upgrade safety (7.7 Upgrades). However, the use of immutable variables for MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD means these foundational parameters cannot be altered in future upgrades. While a design choice, this limits flexibility if initial parameters prove suboptimal, potentially necessitating a new contract deployment rather than an upgrade (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is strongly recommended to address the identified integer overflow vulnerability immediately to prevent critical system failures.

The project should also consider decentralizing control over critical state transitions by implementing a multi-signature wallet or a time-lock mechanism for owner-privileged functions. Furthermore, introducing owner-controlled functions to update key economic parameters will significantly improve the protocol's adaptability and reduce the need for costly and complex contract upgrades. Thorough testing, especially across all PoolState transitions, is advised.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age22d

Contract0xdbc6…7777

Deployer0xf3e4…83cb

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, 202655Medium
Aug 30, 202636Medium

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

Frequently Asked Questions

What is the BICAT contract address?

The Bicat contract on BNB Chain is 0xdbc6333a7d8bcd95f96641eda4d095e69f207777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.