Is 4cat a Scam? Security Analysis

Security Findings

1 High2 Med2 Low1 Info

High

Centralized Control Over Critical Parameters and Blacklisting

H-01The contract grants significant centralized control to several privileged roles. The `tokenModule` address can call `postInitialize` to set critical external contract addresses like `tokenHelper`, `shareHolderManager`, and `lpV2Manager`. The `shareHolderManager` contract, once set, can blacklist users from transferring tokens via its `isBlacklisted` function. Additionally, `onlyTaxVault` and `onlyMigrateModule` modifiers restrict access to specific functions to `vault` and `migrateModule` addresses, respectively. This concentration of power introduces a single point of failure and potential for censorship or malicious manipulation of the protocol's core functionality and user access.

IssueThe contract grants significant centralized control to several privileged roles. The `tokenModule` address can call `postInitialize` to set critical external contract addresses like `tokenHelper`, `shareHolderManager`, and `lpV2Manager`. The `shareHolderManager` contract, once set, can blacklist users from transferring tokens via its `isBlacklisted` function. Additionally, `onlyTaxVault` and `onlyMigrateModule` modifiers restrict access to specific functions to `vault` and `migrateModule` addresses, respectively. This concentration of power introduces a single point of failure and potential for censorship or malicious manipulation of the protocol's core functionality and user access.

FixImplement multi-signature wallets for all privileged roles (`tokenModule`, `vault`, `migrateModule`, `shareHolderManager`) to require multiple approvals for critical actions. Clearly document the responsibilities and powers of each role. Consider decentralizing the blacklist mechanism or providing a transparent process for appeals and removals. For critical parameter updates, consider a time-locked governance mechanism.

StatusUnresolved

Medium

Heavy Reliance on External Contracts

M-01The `Stock4TaxToken` contract heavily relies on several external interfaces, including `ITokenHelper`, `IShareHolderManager`, `ITaxVault`, and `IWrappedNative`. The `ITokenHelper` contract, in particular, performs critical swap and liquidity operations. The security and correct functioning of these external contracts are paramount to the integrity and operation of `Stock4TaxToken`. A vulnerability, compromise, or malicious upgrade in any of these external dependencies could directly impact the token's functionality, security, or economic stability.

IssueThe `Stock4TaxToken` contract heavily relies on several external interfaces, including `ITokenHelper`, `IShareHolderManager`, `ITaxVault`, and `IWrappedNative`. The `ITokenHelper` contract, in particular, performs critical swap and liquidity operations. The security and correct functioning of these external contracts are paramount to the integrity and operation of `Stock4TaxToken`. A vulnerability, compromise, or malicious upgrade in any of these external dependencies could directly impact the token's functionality, security, or economic stability.

FixThoroughly audit all external contracts that `Stock4TaxToken` interacts with. Implement robust input validation for addresses set for these external contracts. Consider adding circuit breakers or emergency pause functionalities that can temporarily disable interactions with compromised external contracts if a vulnerability is detected. Ensure that the addresses of these external contracts are immutable or can only be updated through a secure, multi-signature governance process.

StatusUnresolved

Medium

Incomplete Code for Critical Functions

M-02The provided source code for the `Stock4TaxToken` contract is incomplete. Specifically, the `_transfer` function is truncated, and the `_dispatchFee` function is entirely absent from the provided snippet. These functions are central to the token's core logic, handling token transfers, fee collection, and distribution. Without a full review of these critical implementations, it is impossible to thoroughly assess potential vulnerabilities such as reentrancy, incorrect fee calculations, improper handling of edge cases, or other security flaws.

IssueThe provided source code for the `Stock4TaxToken` contract is incomplete. Specifically, the `_transfer` function is truncated, and the `_dispatchFee` function is entirely absent from the provided snippet. These functions are central to the token's core logic, handling token transfers, fee collection, and distribution. Without a full review of these critical implementations, it is impossible to thoroughly assess potential vulnerabilities such as reentrancy, incorrect fee calculations, improper handling of edge cases, or other security flaws.

FixProvide the complete and verified source code for all relevant functions, especially `_transfer` and `_dispatchFee`, for a comprehensive security audit. A full review is essential to ensure the absence of hidden vulnerabilities that could lead to asset loss or protocol malfunction.

StatusUnresolved

Low

High Configurable Sell Fee Rate

L-01The `sellFeeRate` parameter is initialized with a minimum value of 100 (representing 10%) and a maximum of 1000 (representing 100%). While configurable, a default or minimum sell fee of 10% is substantial. Such a high fee can significantly impact user experience, deter trading activity, and potentially lead to reduced liquidity or adoption of the token. Although not a direct security vulnerability, it is an economic parameter that could negatively affect the token's ecosystem.

IssueThe `sellFeeRate` parameter is initialized with a minimum value of 100 (representing 10%) and a maximum of 1000 (representing 100%). While configurable, a default or minimum sell fee of 10% is substantial. Such a high fee can significantly impact user experience, deter trading activity, and potentially lead to reduced liquidity or adoption of the token. Although not a direct security vulnerability, it is an economic parameter that could negatively affect the token's ecosystem.

FixCarefully consider the economic implications of a high sell fee rate. Evaluate if the current minimum and default values align with the project's goals for trading volume and user engagement. Clearly communicate the fee structure to users. Provide mechanisms for governance to adjust these fees if market conditions or project strategy changes.

StatusUnresolved

Low

Potential for Fee Accumulation if Dispatch Thresholds are Misconfigured

L-02The `minDispatch` and `minDispatchQuote` parameters dictate the minimum amounts of accumulated fees required before the `dispatchTax` function can effectively distribute them. If these thresholds are set too high, accumulated fees might remain undistributed for extended periods. This could lead to user dissatisfaction, perceived illiquidity of rewards, or a build-up of a large amount of funds in the contract, potentially making it a more attractive target for attackers, even if protected.

IssueThe `minDispatch` and `minDispatchQuote` parameters dictate the minimum amounts of accumulated fees required before the `dispatchTax` function can effectively distribute them. If these thresholds are set too high, accumulated fees might remain undistributed for extended periods. This could lead to user dissatisfaction, perceived illiquidity of rewards, or a build-up of a large amount of funds in the contract, potentially making it a more attractive target for attackers, even if protected.

FixRegularly monitor the accumulated fees and dispatch activity. Ensure that `minDispatch` and `minDispatchQuote` are set to reasonable values that balance gas costs with timely fee distribution. Consider implementing a mechanism for governance to adjust these thresholds based on network conditions and accumulated fee volumes. Clearly communicate the dispatch mechanics to token holders.

StatusUnresolved

Info

Multi-Step Initialization for Proxy Contract

I-01The contract employs a multi-step initialization process, using both an `initialize` function (protected by `initializer`) and a `postInitialize` function. The `postInitialize` function, which sets critical external addresses, is protected by the `only tokenModule` modifier. While this pattern allows for flexible setup, it adds complexity to the deployment and configuration process. It requires careful management of the `tokenModule` role to ensure that the second initialization phase is executed correctly and securely, without front-running or misconfiguration.

IssueThe contract employs a multi-step initialization process, using both an `initialize` function (protected by `initializer`) and a `postInitialize` function. The `postInitialize` function, which sets critical external addresses, is protected by the `only tokenModule` modifier. While this pattern allows for flexible setup, it adds complexity to the deployment and configuration process. It requires careful management of the `tokenModule` role to ensure that the second initialization phase is executed correctly and securely, without front-running or misconfiguration.

FixEnsure that the `tokenModule` role is assigned to a highly secure, preferably multi-signature, address. Clearly document the sequence and dependencies of the initialization steps. Implement monitoring to detect any unauthorized attempts to call `postInitialize` or any other privileged functions. Consider adding a time-lock for the `postInitialize` call after the initial deployment to provide a window for verification.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes OpenZeppelin's SafeERC20 for secure token operations, mitigating common integer overflow/underflow risks (7.2 Code Security). Reentrancy guards (`swapping`, `dispatchingFee`) are implemented for the `dispatchTax` function, which is a positive security measure. However, the audit was limited by the truncation of the `_transfer` function and the absence of the `_dispatchFee` implementation, which are critical for a full assessment of code security and potential reentrancy vectors (7.2 Code Security). The architecture (7.1 Architecture) involves multiple external contract interactions, increasing the attack surface.

GovernanceMedium5/10

The contract exhibits significant centralization through various privileged roles (7.3 Access Control). The `tokenModule` can configure critical external addresses via `postInitialize`, and the `shareHolderManager` can blacklist users, introducing a single point of failure and censorship risk (7.3 Access Control). The tokenomics include configurable buy and sell fee rates, with a minimum sell fee of 10% (7.4 Economic). While flexible, this high minimum could deter trading. The `minDispatch` and `minDispatchQuote` parameters control fee distribution, and if misconfigured, could lead to prolonged accumulation of undistributed fees (7.4 Economic).

UpgradesLow8/10

The contract is deployed as an upgradeable proxy, utilizing the `initializer` modifier for its `initialize` function (7.7 Upgrades). A `postInitialize` function is also present, protected by the `tokenModule` role, which sets critical external dependencies. This multi-step initialization adds complexity to the deployment and setup process (7.7 Upgrades). Proper management of the `tokenModule` role is crucial to prevent unauthorized configuration during the second initialization phase.

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

42.6% in top 10

0.0% in wallets42.6% in contracts

Effective Concentration17.0%

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

$34.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

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x5745…95ae

Unlocked LP Held By

0x1584…cb02

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
Liquidity < $50k ($34,395 across 1 pairs — thin market)
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 30 days (still settling)
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

It is strongly recommended to conduct a thorough review of the complete source code, especially the `_transfer` and `_dispatchFee` functions, to ensure all security considerations are addressed.…

Read the verdictHide

Implement robust access control mechanisms and multi-signature wallets for all privileged roles (`tokenModule`, `vault`, `migrateModule`, `shareHolderManager`) to mitigate centralization risks. Carefully evaluate and document the trust assumptions for all external contracts, such as `ITokenHelper` and `IShareHolderManager`, and consider implementing circuit breakers or emergency pause functionalities for critical operations. Finally, review the economic parameters, particularly the `sellFeeRate` and dispatch thresholds, to ensure they align with the project's long-term goals and user expectations.

Contract

TypeStock4TaxToken

Audit History

1 audit on record

Sep 2237

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

Not Signed In

Is 4cat a Scam?

Security Findings

Centralized Control Over Critical Parameters and Blacklisting

Heavy Reliance on External Contracts

Incomplete Code for Critical Functions

High Configurable Sell Fee Rate

Potential for Fee Accumulation if Dispatch Thresholds are Misconfigured

Multi-Step Initialization for Proxy Contract

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 4cat?