Quantum Audit Logo

Is Bicat a Scam?

Honeypot, rug-pull and ownership checks

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

Bicat BICAT
0xdbc6…7777
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

2 High2 Medium1 Low1 Informational
i Our automated scanner reviewed Bicat (BICAT) on BNB Chain. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$237.2K
Liquidity
$68.8K
Price
$0.00028
Age
22d
Top 10 Holders
25.3%

Security Findings

2 High2 Med1 Low1 Info
High

Integer Overflow in `finalizeMigration` State Updates

H-01In 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.
IssueIn 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.
FixBefore 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.
StatusUnresolved
High

Centralized Control Over Critical State Transitions

H-02The `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.
IssueThe `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.
FixTo 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.
StatusUnresolved
Medium

Inflexibility of Key Economic Parameters

M-01Several 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.
IssueSeveral 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.
FixImplement 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.
StatusUnresolved
Medium

Potential Flash Loan Manipulation of Liquidation Timing

M-02The `_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.
IssueThe `_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.
FixRe-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.
StatusUnresolved
Low

Complex `_transfer` Logic

L-01The `_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.
IssueThe `_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.
FixConsider 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.
StatusUnresolved
Info

Immutable Thresholds Limit Future Flexibility

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

Category Ratings

TechnicalLow7/10

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 `PoolState`s 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).

GovernanceMedium5/10

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.

UpgradesMedium4/10

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

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

25.3% in top 10
5.3% in wallets20.1% in contracts
Effective Concentration13.3%

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

$69.7K across 5 pairs
Pancakeswap v2QQQBanalysed$68.8K98.7%Pancakeswap v3USDT$8491.2%Uniswap v2USDT$510.1%Pancakeswap v2KING$200.0%Pancakeswap v2BTCBR$00.0%

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

Top-1 Unlocked Holder92.8%
Top-3 Unlocked100.0%

Key Addresses

5 addresses
Deployer
0xf3e4…83cb
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.

What Raised This Score

9 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

Related Audits

6 more on the record
b-moneyHigh RiskTrust Wallet (TWT)High RiskSTABLEHigh RiskOLYHigh RiskVelvetHigh RiskUnibase (UB)High Risk

Would You Like a More Detailed Audit of Bicat?

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

Get Detailed Audit