Is Fuse Cat (FUSECAT) a Scam? New Token Security Check

Security Findings

1 High2 Med1 Low2 Info

High

Centralized Control Over Guard List Initialization

H-01The `initGuardList` function, which sets the whitelist for transfers during the guard period, can only be called once by the `creator` (the `msg.sender` of the constructor). If the `creator` address is compromised, a malicious actor could set an arbitrary guard list, potentially allowing unauthorized transfers during the active guard period. Although the guard period is short (60 seconds), this is a critical access control point (7.3).

IssueThe `initGuardList` function, which sets the whitelist for transfers during the guard period, can only be called once by the `creator` (the `msg.sender` of the constructor). If the `creator` address is compromised, a malicious actor could set an arbitrary guard list, potentially allowing unauthorized transfers during the active guard period. Although the guard period is short (60 seconds), this is a critical access control point (7.3).

FixIf the `creator` address is an EOA, consider using a multi-signature wallet for this role to enhance security. Ensure robust key management practices for the `creator` address. Alternatively, if the guard list is intended to be immutable and known at deployment, consider passing it directly in the constructor.

StatusUnresolved

Medium

Potential DoS for `initGuardList` with Large Input

M-01The `initGuardList` function iterates through the `list` array to set `guardAllowed` for each address. If the `list.length` is excessively large, the transaction could consume too much gas and exceed the block gas limit, leading to a denial-of-service (7.2) for the `creator` attempting to initialize the guard list. This would prevent the guard list from being set, potentially leaving the token in an unintended state regarding transfer restrictions.

IssueThe `initGuardList` function iterates through the `list` array to set `guardAllowed` for each address. If the `list.length` is excessively large, the transaction could consume too much gas and exceed the block gas limit, leading to a denial-of-service (7.2) for the `creator` attempting to initialize the guard list. This would prevent the guard list from being set, potentially leaving the token in an unintended state regarding transfer restrictions.

FixImplement a maximum limit for the `list.length` parameter in `initGuardList` to prevent gas limit issues. Alternatively, consider a paginated approach or a Merkle tree for large whitelists if the list size is expected to be very large.

StatusUnresolved

Medium

Reliance on External `IGuardConfig` for Critical Parameters

M-02The `PairPadLaunchDeployer` contract relies on an external interface, `IGuardConfig(factory)`, to fetch `guardSecondsOf` and `guardListOf` parameters for newly deployed tokens (7.6). If the `factory` contract (which implements `IGuardConfig`) is compromised or returns incorrect values, it could lead to tokens being deployed with unintended or malicious guard configurations, affecting their transferability and economic behavior (7.4). This introduces a trust dependency on the security of the `factory` contract.

IssueThe `PairPadLaunchDeployer` contract relies on an external interface, `IGuardConfig(factory)`, to fetch `guardSecondsOf` and `guardListOf` parameters for newly deployed tokens (7.6). If the `factory` contract (which implements `IGuardConfig`) is compromised or returns incorrect values, it could lead to tokens being deployed with unintended or malicious guard configurations, affecting their transferability and economic behavior (7.4). This introduces a trust dependency on the security of the `factory` contract.

FixEnsure that the `factory` contract implementing `IGuardConfig` is thoroughly audited and secured. Implement robust validation or circuit breakers in the `PairPadLaunchDeployer` if possible, to mitigate risks from a potentially compromised `IGuardConfig` interface, although direct validation of external contract logic is challenging.

StatusUnresolved

Low

Very Short Guard Window Limits Effectiveness

L-01The `MAX_GUARD_SECONDS` constant is set to 60 seconds. While a short guard period limits the duration of potential issues related to the guard mechanism, it also significantly reduces its practical effectiveness (7.4) in providing a meaningful 'launch guard' against immediate post-launch volatility, sniping, or other rapid market manipulations. The guard's utility as a protective measure is minimal due to its brevity.

IssueThe `MAX_GUARD_SECONDS` constant is set to 60 seconds. While a short guard period limits the duration of potential issues related to the guard mechanism, it also significantly reduces its practical effectiveness (7.4) in providing a meaningful 'launch guard' against immediate post-launch volatility, sniping, or other rapid market manipulations. The guard's utility as a protective measure is minimal due to its brevity.

FixReview the intended purpose and desired duration of the launch guard. If a longer protection period is desired, consider increasing `MAX_GUARD_SECONDS`. If the current duration is intentional, ensure this limitation is clearly communicated to users.

StatusUnresolved

Info

`owner()` Function Returns `address(0)`

I-01The `owner()` function, commonly found in OpenZeppelin's `Ownable` contracts, is implemented to explicitly return `address(0)` (7.5). This design choice indicates that the token contract itself does not have a single owner with special privileges post-deployment. While this promotes decentralization, it might be unexpected for users familiar with `Ownable` patterns and means no single entity can perform administrative actions on the token contract (e.g., pausing, upgrading, if it were a proxy).

IssueThe `owner()` function, commonly found in OpenZeppelin's `Ownable` contracts, is implemented to explicitly return `address(0)` (7.5). This design choice indicates that the token contract itself does not have a single owner with special privileges post-deployment. While this promotes decentralization, it might be unexpected for users familiar with `Ownable` patterns and means no single entity can perform administrative actions on the token contract (e.g., pausing, upgrading, if it were a proxy).

FixEnsure that this design choice aligns with the project's decentralization goals and that users are aware of the lack of a traditional owner for the token contract. No action is required if this is the intended design.

StatusUnresolved

Info

Metadata String Length Limits Enforced

I-02The `PairPadLaunchDeployer` contract enforces maximum length limits for metadata fields such as `MAX_NAME_LENGTH`, `MAX_SYMBOL_LENGTH`, `MAX_LOGO_LENGTH`, `MAX_DESCRIPTION_LENGTH`, and `MAX_SOCIAL_LENGTH` (7.2). This is a good practice to prevent excessive gas costs associated with storing and processing very long strings, and to ensure the generated JSON metadata remains manageable. It also helps prevent potential denial-of-service vectors related to oversized data.

IssueThe `PairPadLaunchDeployer` contract enforces maximum length limits for metadata fields such as `MAX_NAME_LENGTH`, `MAX_SYMBOL_LENGTH`, `MAX_LOGO_LENGTH`, `MAX_DESCRIPTION_LENGTH`, and `MAX_SOCIAL_LENGTH` (7.2). This is a good practice to prevent excessive gas costs associated with storing and processing very long strings, and to ensure the generated JSON metadata remains manageable. It also helps prevent potential denial-of-service vectors related to oversized data.

FixNo specific action is required as this is a positive security measure. Ensure that these limits are appropriate for the intended use cases and user experience.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is sound, utilizing OpenZeppelin's ERC20 and ERC20Burnable for core token functionality, which enhances code security (7.2). Immutable variables are used for critical addresses and parameters, improving predictability. However, the `initGuardList` function (7.2) could be susceptible to a denial-of-service if an extremely large list of addresses is provided, potentially exceeding gas limits. Additionally, the `PairPadLaunchDeployer` contract relies on an external `IGuardConfig` interface (7.6) for guard parameters, introducing a dependency on the security and correctness of that external contract.

GovernanceHigh3/10

Access control (7.3) for the `initGuardList` function is centralized to the `creator` address, allowing a single entity to define the initial guard whitelist. While this is a one-time action, compromise of the `creator` could lead to unauthorized whitelisting during the guard period. The economic impact (7.4) of the guard is limited by a very short `MAX_GUARD_SECONDS` (60 seconds), which reduces the window for potential exploitation but also diminishes its protective utility. The `owner()` function (7.5) returns `address(0)`, indicating no single owner post-deployment, promoting decentralization of control over the token itself.

UpgradesLow8/10

The contracts are not designed to be upgradeable (7.7), meaning their logic is immutable once deployed. This simplifies the security model by eliminating risks associated with upgrade mechanisms, such as proxy implementation bugs or upgrade path vulnerabilities. No upgrade safety issues were identified.

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

52.7% in top 10

18.8% in wallets33.9% in contracts

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

$32.5K across 3 pairs

Uniswap v4ETHanalysed$32.2K Uniswap v4USDC$254 Uniswap v4ETH$0

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

0xadd0…6055

Unlocked LP Held By

0x7dc5…24c6

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

What Raised This Score

9 factors

Top-10 concentration > 30% (52.7% total → 32.3% effective; 18.8% in EOAs, 33.9% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($32,473 across 3 pairs — thin market)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
Token age < 7 days (early, volatile)
1 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

Not Signed In

Is Fuse Cat a Scam?

Security Findings

Centralized Control Over Guard List Initialization

Potential DoS for `initGuardList` with Large Input

Reliance on External `IGuardConfig` for Critical Parameters

Very Short Guard Window Limits Effectiveness

`owner()` Function Returns `address(0)`

Metadata String Length Limits Enforced

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 Fuse Cat?