Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Cate a Scam?

CATEEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance6/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7
SummaryAI Copilot

The CATE token contract is an ERC-20 standard implementation with custom tax mechanisms, anti-bot features, and automated liquidity management.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Our automated scanner reviewed Cate (CATE) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
30.7%Contracts19.4%Wallets50.0%Everyone else
30.7%Contracts19.4%Wallets50.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
50.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking30.7%
  • Walletsanonymous holders, free to sell19.4%
  • Everyone elsethe rest of the supply50.0%
Effective concentrationwhat the score reads31.6%
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$96.4K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$94.7KShare of depth98.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
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.

Security Findings

1 Critical2 High2 Medium1 Low1 Info
Critical

Unlocked Liquidity Pool (LP) Poses Rug Pull Risk

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

High

High and Immutable Transaction Taxes

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

High

Fixed Max Transaction and Wallet Size Limits

The _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.H-02

Issue

The _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.

Fix

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

Status

Unresolved

Medium

Immutability of Anti-Bot and Fee Exclusion Lists

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Hardcoded and Immutable Tax Wallet

The _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.M-02

Issue

The _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.

Fix

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

Status

Unresolved

Low

Truncated Code in _transfer Function

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Redundant Use of SafeMath in Solidity 0.8.x

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The CATE token contract is an ERC-20 standard implementation with custom tax mechanisms, anti-bot features, and automated liquidity management. While ownership has been renounced, mitigating some centralization risks, the liquidity pool remains unlocked, posing a critical rug pull vulnerability. The contract also features high, immutable transaction taxes and fixed trading limits, which may hinder adoption and legitimate trading. A portion of the _transfer function was truncated, limiting a complete analysis of its swap logic.

Technical6/10Medium risk

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

Governance6/10Medium risk

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

Upgrades9/10Low risk

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

Final RecommendationWhat to do about this score

Address the critical vulnerability of the unlocked liquidity pool by locking or burning the LP tokens to prevent a rug pull.

Evaluate the impact of the high, immutable transaction taxes and fixed trading limits on token adoption and market health, as these cannot be changed. Consider the implications of the immutable anti-bot and fee exclusion lists, as well as the hardcoded tax wallet, and ensure these configurations are robust and secure for the long term. A full review of the truncated _transfer function is also recommended.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age1y
Contract0xa004…33b8
Deployer0x411a…67b5
Badge for your website
Cate security record badge

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
  1. Sep 4, 202630Low
  2. Jul 29, 202624Low

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

Related Audits

6 more on the recordAll audits
wojakEthereum30LowBalancerBAL · Ethereum30LowApeCoinAPE · Ethereum30LowLinqAILNQ · Ethereum30LowLayerZeroZRO · Ethereum30LowVAIOT TokenVAI · Ethereum30Low

Would You Like a More Detailed Audit of Cate?

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

Get Detailed Audit Is this your token? Publish your own audit on this page