Is Cate a Scam? Security Analysis

Security Findings

1 Crit2 High2 Med1 Low1 Info

Critical

Unlocked Liquidity Pool (LP) Poses Rug Pull Risk

C-01The liquidity pool (LP) tokens for the CATE/WETH pair, created in the constructor, are not locked or burned. The prefill data indicates the LP lock status is 'unlocked'. This means the deployer or current holder of these LP tokens retains the ability to remove liquidity from the Uniswap pair at any time. This action would severely impact the token's price and could lead to a 'rug pull', where investors are left with illiquid tokens.

IssueThe liquidity pool (LP) tokens for the CATE/WETH pair, created in the constructor, are not locked or burned. The prefill data indicates the LP lock status is 'unlocked'. This means the deployer or current holder of these LP tokens retains the ability to remove liquidity from the Uniswap pair at any time. This action would severely impact the token's price and could lead to a 'rug pull', where investors are left with illiquid tokens.

FixImmediately lock the LP tokens using a reputable locker service or burn them to a null address. This action should be publicly verifiable to build trust and prevent a rug pull.

StatusUnresolved

High

High and Immutable Transaction Taxes

H-01The contract initializes with high buy and sell taxes of 20% (`_initialBuyTax`, `_initialSellTax`). While these are designed to reduce after `_reduceBuyTaxAt` and `_reduceSellTaxAt` thresholds (set to 10), the initial high taxes apply for the first 10 transactions. After ownership renunciation, these tax rates and reduction thresholds are immutable. Such high and fixed taxes can deter legitimate trading, reduce liquidity, and negatively impact token adoption and market activity.

IssueThe contract initializes with high buy and sell taxes of 20% (`_initialBuyTax`, `_initialSellTax`). While these are designed to reduce after `_reduceBuyTaxAt` and `_reduceSellTaxAt` thresholds (set to 10), the initial high taxes apply for the first 10 transactions. After ownership renunciation, these tax rates and reduction thresholds are immutable. Such high and fixed taxes can deter legitimate trading, reduce liquidity, and negatively impact token adoption and market activity.

FixFor future deployments, consider lower initial tax rates to encourage trading. Since ownership is renounced, these parameters cannot be changed. The project should clearly communicate these fixed tax structures to the community.

StatusUnresolved

High

Fixed Max Transaction and Wallet Size Limits

H-02The `_maxTxAmount` and `_maxWalletSize` are both set to 1% of the total supply. After ownership renunciation, these limits are immutable. While intended to prevent large whale manipulation, these fixed limits can restrict legitimate large transactions, prevent users from accumulating significant holdings, and potentially hinder participation from large investors or exchanges. This rigidity can negatively impact market dynamics and token distribution.

IssueThe `_maxTxAmount` and `_maxWalletSize` are both set to 1% of the total supply. After ownership renunciation, these limits are immutable. While intended to prevent large whale manipulation, these fixed limits can restrict legitimate large transactions, prevent users from accumulating significant holdings, and potentially hinder participation from large investors or exchanges. This rigidity can negatively impact market dynamics and token distribution.

FixFor future deployments, carefully evaluate the impact of such strict limits on market behavior and adoption. Since ownership is renounced, these parameters cannot be changed. The project should clearly communicate these fixed limits to the community.

StatusUnresolved

Medium

Immutability of Anti-Bot and Fee Exclusion Lists

M-01The `bots` mapping and `_isExcludedFromFee` mapping are fixed after ownership renunciation. This means the contract owner can no longer add or remove addresses from these lists. This rigidity prevents adaptation to new bot strategies, correction of accidental exclusions/inclusions, or the ability to grant fee exemptions to new legitimate entities (e.g., exchanges, liquidity providers) in the future.

IssueThe `bots` mapping and `_isExcludedFromFee` mapping are fixed after ownership renunciation. This means the contract owner can no longer add or remove addresses from these lists. This rigidity prevents adaptation to new bot strategies, correction of accidental exclusions/inclusions, or the ability to grant fee exemptions to new legitimate entities (e.g., exchanges, liquidity providers) in the future.

FixFor future deployments, consider a mechanism for community governance or a multi-sig to manage these lists if flexibility is desired post-renunciation. Since ownership is renounced, these lists are now permanent.

StatusUnresolved

Medium

Hardcoded and Immutable Tax Wallet

M-02The `_taxWallet` address (0x411A…67b5) is hardcoded in the constructor and cannot be changed after ownership renunciation. If this wallet is compromised, becomes inaccessible, or is an incorrect address, all accumulated tax funds will be permanently lost or misdirected without any recourse. This introduces a single point of failure for the collected taxes.

IssueThe `_taxWallet` address () is hardcoded in the constructor and cannot be changed after ownership renunciation. If this wallet is compromised, becomes inaccessible, or is an incorrect address, all accumulated tax funds will be permanently lost or misdirected without any recourse. This introduces a single point of failure for the collected taxes.

FixFor future deployments, consider making the tax wallet address configurable by a multi-sig or governance, even if ownership is renounced. Since ownership is renounced, this address is now permanent. Ensure the hardcoded address is secure and properly managed.

StatusUnresolved

Low

Truncated Code in `_transfer` Function

L-01The provided source code for the `_transfer` function is truncated, specifically within the `if (!inSwap ...)` block, ending at `block.numbe...`. This prevents a complete and thorough security analysis of the swap-and-liquify mechanism and its interaction with `block.number` or `lastSellBlock` for potential cooldowns or timing-related vulnerabilities.

IssueThe provided source code for the `_transfer` function is truncated, specifically within the `if (!inSwap ...)` block, ending at `block.numbe...`. This prevents a complete and thorough security analysis of the swap-and-liquify mechanism and its interaction with `block.number` or `lastSellBlock` for potential cooldowns or timing-related vulnerabilities.

FixProvide the complete and untruncated source code for a comprehensive security audit. Without the full code, assumptions must be made, and potential vulnerabilities in the missing section cannot be identified.

StatusUnresolved

Info

Redundant Use of SafeMath in Solidity 0.8.x

I-01The contract uses the `SafeMath` library for arithmetic operations. While this was a critical best practice in older Solidity versions (prior to 0.8.0) to prevent integer overflow/underflow, Solidity 0.8.0 and later versions include built-in overflow and underflow checks by default. Therefore, the explicit use of `SafeMath` for basic arithmetic operations is largely redundant and adds unnecessary code complexity and gas overhead.

IssueThe contract uses the `SafeMath` library for arithmetic operations. While this was a critical best practice in older Solidity versions (prior to 0.8.0) to prevent integer overflow/underflow, Solidity 0.8.0 and later versions include built-in overflow and underflow checks by default. Therefore, the explicit use of `SafeMath` for basic arithmetic operations is largely redundant and adds unnecessary code complexity and gas overhead.

FixFor future contracts compiled with Solidity 0.8.0 or higher, consider removing the `SafeMath` library and relying on Solidity's native overflow/underflow checks. This can reduce contract size and gas costs slightly.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes `SafeMath` for arithmetic safety and implements standard ERC-20 functionalities. It includes a complex `_transfer` function with dynamic tax calculations, anti-bot measures, and automated liquidity provision. The `lockTheSwap` modifier helps prevent reentrancy during liquidity swaps (7.2 Code Security). However, the provided code for the `_transfer` function is truncated, preventing a full analysis of its swap logic (7.1 Architecture). The contract's reliance on fixed parameters after ownership renunciation introduces rigidity, as the `bots` mapping and `_isExcludedFromFee` list cannot be updated (7.3 Access Control).

GovernanceMedium6/10

The contract's ownership has been renounced, which removes the risk of the owner arbitrarily changing parameters post-deployment (7.5 Governance). However, the liquidity pool for the CATE/WETH pair is unlocked, presenting a critical rug pull vulnerability (7.4 Economic). Furthermore, the contract features high initial buy and sell taxes (20%) and fixed maximum transaction/wallet size limits, which are now immutable and could negatively impact token usability and market dynamics (7.4 Economic). The hardcoded and immutable tax wallet also poses a risk if compromised (7.8 Operations).

UpgradesLow9/10

The CATE contract is not designed with an upgrade proxy pattern, meaning its core logic cannot be directly upgraded (7.7 Upgrades). While this ensures immutability of the contract code, the renounced ownership also means that all configurable parameters, such as taxes, trading limits, and bot lists, are permanently fixed. This lack of flexibility prevents any future adjustments or bug fixes to these parameters, even if necessary for the token's health or security (7.7 Upgrades).

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

50.0% in top 10

19.4% in wallets30.7% in contracts

Effective Concentration31.6%

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

$96.4K across 3 pairs

Uniswap v2WETHanalysed$94.7K Uniswap v4ETH$950 Uniswap v3WETH$665

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 Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

3 addresses

Deployer

0x411a…67b5

Unlocked LP Held By

0x7807…0cf30x1f2f…f387

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

What Raised This Score

5 factors

Top-10 concentration > 30% (50.0% total → 31.6% effective; 19.4% in EOAs, 30.7% in contracts — moderate)
1 Critical finding(s) from audit
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

Is Cate a Scam?

Security Findings

Unlocked Liquidity Pool (LP) Poses Rug Pull Risk

High and Immutable Transaction Taxes

Fixed Max Transaction and Wallet Size Limits

Immutability of Anti-Bot and Fee Exclusion Lists

Hardcoded and Immutable Tax Wallet

Truncated Code in `_transfer` Function

Redundant Use of SafeMath in Solidity 0.8.x

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 Cate?