Is Bitcat a Scam? New Token Security Check

Security Findings

1 Crit1 High1 Med1 Low2 Info

Critical

Critical Code Truncation in `_liquidateTax` Function

C-01The provided source code for the `_liquidateTax` function is truncated, specifically after the line `|| taxAmount >= currentPoolState.liqu...`. This prevents a complete audit of the function's logic, including its full conditions for liquidation, potential external calls, and state modifications. Any unreviewed code could contain critical vulnerabilities such as reentrancy, access control bypasses, or economic exploits (7.2, 7.6, 7.8).

IssueThe provided source code for the `_liquidateTax` function is truncated, specifically after the line `|| taxAmount >= currentPoolState.liqu...`. This prevents a complete audit of the function's logic, including its full conditions for liquidation, potential external calls, and state modifications. Any unreviewed code could contain critical vulnerabilities such as reentrancy, access control bypasses, or economic exploits (7.2, 7.6, 7.8).

FixProvide the complete and verified source code for the `_liquidateTax` function. A full security review of this critical component is essential to ensure the contract's integrity and security.

StatusUnresolved

High

Centralized Control Over Critical State Transitions

H-01The `startMigration` and `finalizeMigration` functions, which control significant state changes in the token's lifecycle, are protected only by the `onlyOwner` modifier. This grants a single address (the contract owner) unilateral control over these critical transitions. A compromise of the owner's private key could lead to unauthorized state changes, potentially disrupting token functionality or economic model (7.3, 7.5).

IssueThe `startMigration` and `finalizeMigration` functions, which control significant state changes in the token's lifecycle, are protected only by the `onlyOwner` modifier. This grants a single address (the contract owner) unilateral control over these critical transitions. A compromise of the owner's private key could lead to unauthorized state changes, potentially disrupting token functionality or economic model (7.3, 7.5).

FixConsider implementing a multi-signature wallet or a time-locked governance mechanism for critical owner-only functions like `startMigration` and `finalizeMigration`. This would introduce a delay or require multiple approvals, reducing the risk associated with a single point of failure.

StatusUnresolved

Medium

Potential Gas Cost and Unexpected Behavior from `_liquidateTax` Invocation

M-01The `_liquidateTax` function is called internally within `_transfer` whenever a transfer is made to the `mainPool`. Given that the full logic of `_liquidateTax` is unknown due to truncation, there's a risk that this function could perform complex operations, external calls, or significant state changes. This could lead to unexpectedly high gas costs for users transferring to the `mainPool` or introduce reentrancy vectors if external calls are made without proper reentrancy guards (7.2, 7.8).

IssueThe `_liquidateTax` function is called internally within `_transfer` whenever a transfer is made to the `mainPool`. Given that the full logic of `_liquidateTax` is unknown due to truncation, there's a risk that this function could perform complex operations, external calls, or significant state changes. This could lead to unexpectedly high gas costs for users transferring to the `mainPool` or introduce reentrancy vectors if external calls are made without proper reentrancy guards (7.2, 7.8).

FixOnce the full `_liquidateTax` code is available, thoroughly review its complexity and gas implications. If it performs heavy operations, consider optimizing it or decoupling its execution from every transfer. Implement reentrancy guards (e.g., ReentrancyGuard) if external calls are made to untrusted contracts.

StatusUnresolved

Low

Long-Term `uint48` Truncation Risk for `antiFarmerExpirationTime`

L-01The `antiFarmerExpirationTime` variable is stored as `uint48`. While `block.timestamp` currently fits within `uint48` (representing approximately 270,000 years), in the extremely long term (hundreds of thousands of years), `block.timestamp` could exceed the maximum value of `uint48`. This could lead to truncation or unexpected behavior if the contract is intended to operate over such extended periods (7.2).

IssueThe `antiFarmerExpirationTime` variable is stored as `uint48`. While `block.timestamp` currently fits within `uint48` (representing approximately 270,000 years), in the extremely long term (hundreds of thousands of years), `block.timestamp` could exceed the maximum value of `uint48`. This could lead to truncation or unexpected behavior if the contract is intended to operate over such extended periods (7.2).

FixFor time-related variables that store `block.timestamp` or future timestamps, it is generally safer to use `uint256` to avoid any potential long-term truncation issues, even if the immediate risk is negligible. Alternatively, ensure that `antiFarmerDuration` is always small enough such that `block.timestamp + antiFarmerDuration` will not exceed `uint48` max.

StatusUnresolved

Info

Initial Token Distribution to Initializer

I-01During the `initialize` function, the entire `maxSupply` (1 billion tokens) is minted to `msg.sender`. This means the address that calls `initialize` will hold the entire initial supply of tokens. While a common pattern for new tokens, it centralizes the initial distribution (7.4).

IssueDuring the `initialize` function, the entire `maxSupply` (1 billion tokens) is minted to `msg.sender`. This means the address that calls `initialize` will hold the entire initial supply of tokens. While a common pattern for new tokens, it centralizes the initial distribution (7.4).

FixEnsure that the address used to call `initialize` is a secure, controlled entity (e.g., a multi-signature wallet or a cold wallet) and that the project's token distribution strategy is clearly communicated to the community.

StatusUnresolved

Info

Unused Public State Variables

I-02Several public state variables (`v2Router`, `liqExpectedOutputAmount`, `metaURI`, `dividendContract`, `initialLiquidationThreshold`) are declared and initialized but not explicitly used within the provided (non-truncated) functions of the `FlapTaxTokenV3` contract. While they might be used in the truncated `_liquidateTax` function or external interfaces, their current apparent lack of use could indicate dead code or incomplete functionality (7.1).

IssueSeveral public state variables (`v2Router`, `liqExpectedOutputAmount`, `metaURI`, `dividendContract`, `initialLiquidationThreshold`) are declared and initialized but not explicitly used within the provided (non-truncated) functions of the `FlapTaxTokenV3` contract. While they might be used in the truncated `_liquidateTax` function or external interfaces, their current apparent lack of use could indicate dead code or incomplete functionality (7.1).

FixReview the contract's design to confirm if these variables are intended for future use, external interactions (e.g., by `taxProcessor` or `dividendContract`), or if they are indeed unused. If unused, consider removing them to reduce contract complexity and deployment costs. If they are used in the truncated code, this will become clear upon full code review.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable patterns and `SafeERC20` for secure token interactions, demonstrating a solid foundation for code security (7.2). The `PackedPoolState` struct efficiently manages complex state variables. However, a critical portion of the `_liquidateTax` function is truncated, preventing a full security assessment of its logic and potential vulnerabilities (7.2). Additionally, the frequent invocation of `_liquidateTax` on transfers to `mainPool` could lead to unexpected gas costs or state changes (7.8).

GovernanceMedium4/10

The contract defines immutable liquidation thresholds and uses a clear tax calculation mechanism, contributing to predictable economic behavior (7.4). However, the `OwnableUpgradeable` pattern grants the owner significant control over critical state transitions, such as `startMigration` and `finalizeMigration` (7.3, 7.5). The entire `maxSupply` is minted to the initializer, centralizing initial token distribution (7.4). This high degree of centralized control introduces governance risks.

UpgradesLow8/10

The contract correctly implements OpenZeppelin's `Initializable` pattern, including `_disableInitializers()` in the constructor and the `initializer` modifier, which mitigates re-initialization risks (7.7). This standard approach provides a robust and secure upgrade mechanism. No immediate upgrade safety issues were identified within the provided code.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

26.7% in top 10

5.0% in wallets21.7% in contracts

Effective Concentration13.7%

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

$77.0K across 2 pairs

Pancakeswap v2BTCBanalysed$77.0K Uniswap v2USDT$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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x7eb1…8e84

Unlocked LP Held By

0xddac…308c

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

What Raised This Score

8 factors

Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 7 days (early, volatile)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 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

Not Signed In

Is Bitcat a Scam?

Security Findings

Critical Code Truncation in `_liquidateTax` Function

Centralized Control Over Critical State Transitions

Potential Gas Cost and Unexpected Behavior from `_liquidateTax` Invocation

Long-Term `uint48` Truncation Risk for `antiFarmerExpirationTime`

Initial Token Distribution to Initializer

Unused Public State Variables

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Bitcat?