Is Tsutsuji the Cate (CATE) a Scam? Security Analysis

Security Findings

1 Crit1 High2 Med2 Low1 Info

Critical

Truncated `swapTokensForEth` Function

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

IssueThe `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.

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

StatusUnresolved

High

Uncontrolled `bots` Mapping

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

IssueThe `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.

FixImplement `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.

StatusUnresolved

Medium

Complex and Potentially Conflicting Tax Logic

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

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

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

StatusUnresolved

Medium

Centralization of Control

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

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

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

StatusUnresolved

Low

Hardcoded `_taxWallet` Address

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

IssueThe `_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.

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

StatusUnresolved

Low

`renounceOwnership` Risk

L-02The `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.

IssueThe `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.

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

StatusUnresolved

Info

Limitations of Anti-Bot/Anti-Dump Mechanisms

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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

GovernanceLow7/10

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

UpgradesLow9/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

31.0% in top 10

13.2% in wallets17.8% in contracts

Effective Concentration20.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

$38.4K

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

2 addresses

Deployer

0x01d3…8ea2

Unlocked LP Held By

0xf385…5f85

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

What Raised This Score

6 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeRouter, Token

Audit History

1 audit on record

Sep 322

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

Is Tsutsuji the Cate a Scam?

Security Findings

Truncated `swapTokensForEth` Function

Uncontrolled `bots` Mapping

Complex and Potentially Conflicting Tax Logic

Centralization of Control

Hardcoded `_taxWallet` Address

`renounceOwnership` Risk

Limitations of Anti-Bot/Anti-Dump Mechanisms

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