Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Tsutsuji the 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
Technical7/10Governance7/10Upgrades9/10Checks passed7 of 7Findings1 Critical · 1 High · 2 Medium · 2 Low · 1 Info7
SummaryAI Copilot

The CATE token contract implements standard ERC-20 functionality with advanced tokenomics including transaction taxes, anti-bot measures, and automatic liquidity provision.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • Liquidity < $50k
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (31.0% total → 20.3% effective; 13.2% in EOAs, 17.8% in contracts — mild)
  • Liquidity < $50k ($38,400 across 1 pairs — thin market)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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 Tsutsuji the Cate (CATE) on Ethereum. 7 of 7 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
17.8%Contracts13.2%Wallets69.0%Everyone else
17.8%Contracts13.2%Wallets69.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
31.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking17.8%
  • Walletsanonymous holders, free to sell13.2%
  • Everyone elsethe rest of the supply69.0%
Effective concentrationwhat the score reads20.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$38.4K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$38.4KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0xf385…5f85

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

Security Findings

1 Critical1 High2 Medium2 Low1 Info
Critical

Truncated swapTokensForEth Function

The swapTokensForEth function, which is critical for the contract's automatic liquidity provision and tax handling, is incomplete in the provided source code. This prevents a full security assessment of its logic, including potential reentrancy vectors, incorrect ETH handling, or other critical vulnerabilities that could lead to loss of funds or contract malfunction. Without the full implementation, the contract's core economic mechanism cannot be verified.C-01

Issue

The swapTokensForEth function, which is critical for the contract's automatic liquidity provision and tax handling, is incomplete in the provided source code. This prevents a full security assessment of its logic, including potential reentrancy vectors, incorrect ETH handling, or other critical vulnerabilities that could lead to loss of funds or contract malfunction. Without the full implementation, the contract's core economic mechanism cannot be verified.

Fix

Provide the complete and accurate source code for the swapTokensForEth function to allow for a comprehensive security audit. Ensure the function correctly handles ETH transfers, prevents reentrancy, and interacts with the Uniswap router as intended.

Status

Unresolved

High

Uncontrolled bots Mapping

The bots mapping is used within the _transfer function (require(!bots[from] && !bots[to])) to restrict transfers from or to identified bot addresses. However, there are no functions provided in the contract to add or remove addresses from this bots mapping. This renders the anti-bot mechanism ineffective, as the mapping will always remain empty, or if it was intended to be pre-populated, it cannot be updated or corrected.H-01

Issue

The bots mapping is used within the _transfer function (require(!bots[from] && !bots[to])) to restrict transfers from or to identified bot addresses. However, there are no functions provided in the contract to add or remove addresses from this bots mapping. This renders the anti-bot mechanism ineffective, as the mapping will always remain empty, or if it was intended to be pre-populated, it cannot be updated or corrected.

Fix

Implement onlyOwner functions to allow the contract owner to add and remove addresses from the bots mapping. This will enable the anti-bot mechanism to be actively managed and effective.

Status

Unresolved

Medium

Complex and Potentially Conflicting Tax Logic

The tax calculation logic within the _transfer function is highly complex, involving multiple if conditions, _buyCount checks, and different tax rates (_initialBuyTax, _finalBuyTax, _transferTax, _initialSellTax, _finalSellTax). The interaction between these conditions, especially for non-LP transfers versus LP buys/sells, is not immediately clear and could lead to unexpected tax amounts or confusion. For example, the if(_buyCount==0) and if(_buyCount>0) blocks might conflict or be overridden by the LP-specific tax calculations.M-01

Issue

The tax calculation logic within the _transfer function is highly complex, involving multiple if conditions, _buyCount checks, and different tax rates (_initialBuyTax, _finalBuyTax, _transferTax, _initialSellTax, _finalSellTax). The interaction between these conditions, especially for non-LP transfers versus LP buys/sells, is not immediately clear and could lead to unexpected tax amounts or confusion. For example, the if(_buyCount==0) and if(_buyCount>0) blocks might conflict or be overridden by the LP-specific tax calculations.

Fix

Simplify the tax calculation logic where possible. Clearly define the order of precedence for tax application. Add comprehensive unit tests to cover all possible transfer scenarios (LP buy, LP sell, wallet-to-wallet, excluded addresses) and verify that the correct tax amounts are applied under various _buyCount and tax rate configurations.

Status

Unresolved

Medium

Centralization of Control

The contract utilizes the Ownable pattern, granting a single address (the owner) extensive control over critical contract parameters. The owner can modify tax rates (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax, _transferTax), transaction limits (_maxTxAmount, _maxWalletSize), liquidity swap thresholds (_taxSwapThreshold, _maxTaxSwap), and exclude addresses from fees (_isExcludedFromFee). This high degree of centralization introduces a single point of failure and potential for malicious or accidental misuse of power.M-02

Issue

The contract utilizes the Ownable pattern, granting a single address (the owner) extensive control over critical contract parameters. The owner can modify tax rates (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax, _transferTax), transaction limits (_maxTxAmount, _maxWalletSize), liquidity swap thresholds (_taxSwapThreshold, _maxTaxSwap), and exclude addresses from fees (_isExcludedFromFee). This high degree of centralization introduces a single point of failure and potential for malicious or accidental misuse of power.

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract's ownership to distribute control and require multiple approvals for critical operations. This enhances security by mitigating the risk associated with a single compromised or malicious owner key.

Status

Unresolved

Low

Hardcoded _taxWallet Address

The _taxWallet address, which receives all collected taxes, is hardcoded in the constructor (`_taxWallet = payable(0xDdD2…fC5F);`). This means the address cannot be changed after deployment. If the tax wallet address needs to be updated in the future (e.g., due to compromise, change in operational structure, or migration), there is no mechanism to do so, potentially leading to a loss of collected funds or operational inflexibility.L-01

Issue

The _taxWallet address, which receives all collected taxes, is hardcoded in the constructor (`_taxWallet = payable();`). This means the address cannot be changed after deployment. If the tax wallet address needs to be updated in the future (e.g., due to compromise, change in operational structure, or migration), there is no mechanism to do so, potentially leading to a loss of collected funds or operational inflexibility.

Fix

Implement an onlyOwner function to allow the contract owner to update the _taxWallet address. This provides flexibility for future operational changes while maintaining appropriate access control.

Status

Unresolved

Low

renounceOwnership Risk

The renounceOwnership function allows the current owner to permanently transfer ownership to the zero address (address(0)). If this function is called, the contract will become unmanageable, as no address will be able to perform onlyOwner restricted functions (e.g., updating tax parameters, managing excluded addresses, or fixing issues). While this is a standard Ownable function, its accidental or malicious invocation would render the contract's administrative features unusable.L-02

Issue

The renounceOwnership function allows the current owner to permanently transfer ownership to the zero address (address(0)). If this function is called, the contract will become unmanageable, as no address will be able to perform onlyOwner restricted functions (e.g., updating tax parameters, managing excluded addresses, or fixing issues). While this is a standard Ownable function, its accidental or malicious invocation would render the contract's administrative features unusable.

Fix

Ensure that the implications of calling renounceOwnership are fully understood by the owner. If the intention is to maintain administrative control, this function should not be called. For enhanced security, consider removing this function if permanent owner control is desired, or add a time-lock/multi-sig confirmation for its execution.

Status

Unresolved

Info

Limitations of Anti-Bot/Anti-Dump Mechanisms

The contract implements several mechanisms to limit large transactions and prevent rapid price manipulation, such as _maxTxAmount, _maxWalletSize, and sellCount < 3 per block. While these measures are effective to a degree, they can be circumvented by sophisticated actors using multiple wallets, splitting transactions, or waiting for new blocks. The _preventSwapBefore mechanism also delays auto-liquidity for the first 20 buys, which could impact initial price stability.I-01

Issue

The contract implements several mechanisms to limit large transactions and prevent rapid price manipulation, such as _maxTxAmount, _maxWalletSize, and sellCount < 3 per block. While these measures are effective to a degree, they can be circumvented by sophisticated actors using multiple wallets, splitting transactions, or waiting for new blocks. The _preventSwapBefore mechanism also delays auto-liquidity for the first 20 buys, which could impact initial price stability.

Fix

Acknowledge that such mechanisms, while helpful, are not foolproof. Continuously monitor trading activity and be prepared to adapt strategies if these limitations are exploited. Clearly communicate these mechanisms to the community to manage expectations.

Status

Unresolved

Analysis

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

The CATE token contract implements standard ERC-20 functionality with advanced tokenomics including transaction taxes, anti-bot measures, and automatic liquidity provision. While SafeMath is used to prevent integer overflows, a critical portion of the swapTokensForEth function is truncated, preventing a full security assessment. Additionally, the bots mapping, intended for security, lacks control mechanisms, rendering it ineffective. The contract exhibits a high degree of centralization through its Ownable pattern, allowing the owner to control key parameters.

Technical7/10Low risk

The contract utilizes SafeMath for arithmetic safety and includes a reentrancy guard (lockTheSwap) for the swapTokensForEth function (7.2 Code Security). However, the provided code for swapTokensForEth is incomplete, which prevents a thorough security analysis of its critical liquidity management logic. A significant access control flaw exists with the bots mapping, which is used to restrict transfers but has no owner-controlled mechanism to add or remove addresses (7.3 Access Control).

Governance7/10Low risk

The contract implements a complex tax structure with initial buy/sell taxes, a transfer tax, and mechanisms for tax reduction based on _buyCount. This design aims to manage tokenomics and prevent large dumps (7.4 Economic). However, the intricate tax logic may lead to unexpected behavior or confusion. The contract is highly centralized, with the owner having control over critical parameters such as tax rates, max transaction amounts, and wallet sizes (7.5 Governance). The _taxWallet is hardcoded, limiting flexibility (7.8 Operations).

Upgrades9/10Low risk

The contract is not designed with an upgradeability pattern (e.g., UUPS, Transparent Proxies). This means that once deployed, its logic cannot be modified or updated (7.7 Upgrades). Any discovered vulnerabilities or desired feature changes would necessitate a new contract deployment and migration, which can be costly and disruptive to the community.

Final RecommendationWhat to do about this score

Prioritize completing the swapTokensForEth function and conducting a thorough review of its logic, especially regarding ETH handling and external calls.

Implement proper access control for the bots mapping to ensure its intended security function is operational. Review the complex tax logic to simplify it where possible and ensure all conditions interact as intended, preventing unexpected outcomes. Consider implementing a multi-signature wallet for ownership to mitigate centralization risks and protect against a single point of failure. If the _taxWallet needs to be mutable, add an onlyOwner function to update it. Ensure all critical parameters are clearly documented and tested to prevent misconfigurations.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age1y
Contract0x712f…8683
Deployer0x01d3…8ea2
Badge for your website
Tsutsuji the 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 3, 202622Low

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

Related Audits

6 more on the recordAll audits
SpiralEthereum22LowBook of EthereumBOOE · Ethereum21LowOGEthereum23LowclausEthereum21LowAsteroid ShibaASTEROID · Ethereum20LowClawdEthereum24Low

Would You Like a More Detailed Audit of Tsutsuji the 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