Is Fuse a Scam? New Token Security Check

Security Findings

1 High1 Med2 Low2 Info

High

Critical Dependency on `IGuardConfig` Implementation

H-01The `PairPadLaunchDeployer` contract critically relies on the `IGuardConfig` interface, specifically `guardSecondsOf` and `guardListOf`, which are called on the `factory` address. The security and integrity of the token's launch guard mechanism (duration and allowed list) are entirely dependent on the correct and non-malicious implementation of these functions within the `factory` contract. A compromised or malicious `factory` could provide incorrect guard configurations, potentially allowing unauthorized transfers during the guard period or disabling the guard entirely. This introduces a significant trust assumption on the `factory` contract (7.6 External).

IssueThe `PairPadLaunchDeployer` contract critically relies on the `IGuardConfig` interface, specifically `guardSecondsOf` and `guardListOf`, which are called on the `factory` address. The security and integrity of the token's launch guard mechanism (duration and allowed list) are entirely dependent on the correct and non-malicious implementation of these functions within the `factory` contract. A compromised or malicious `factory` could provide incorrect guard configurations, potentially allowing unauthorized transfers during the guard period or disabling the guard entirely. This introduces a significant trust assumption on the `factory` contract (7.6 External).

FixEnsure the `factory` contract implementing `IGuardConfig` is thoroughly audited, highly secure, and its access controls are robust. Consider adding safeguards or multi-signature approvals for changes to the `factory`'s guard configuration logic. Document this critical dependency clearly for users and `originalDeployer`s.

StatusUnresolved

Medium

Centralized Control over Guard List Initialization

M-01The `creator` of `PairPadLauncherToken` is the `PairPadLaunchDeployer` contract itself, not the `originalDeployer` who initiated the token creation. Consequently, only the `PairPadLaunchDeployer` can call `initGuardList` on the newly deployed token. This means the `originalDeployer` has no direct control over the initialization of the guard list; it is entirely dictated by the `PairPadLaunchDeployer` based on the configuration fetched from `IGuardConfig(factory)`. This centralizes a critical initial setup step (7.3 Access Control, 7.5 Governance).

IssueThe `creator` of `PairPadLauncherToken` is the `PairPadLaunchDeployer` contract itself, not the `originalDeployer` who initiated the token creation. Consequently, only the `PairPadLaunchDeployer` can call `initGuardList` on the newly deployed token. This means the `originalDeployer` has no direct control over the initialization of the guard list; it is entirely dictated by the `PairPadLaunchDeployer` based on the configuration fetched from `IGuardConfig(factory)`. This centralizes a critical initial setup step (7.3 Access Control, 7.5 Governance).

FixIf the `originalDeployer` is intended to have more direct control or oversight, consider modifying the design to allow them to propose or approve the guard list before `PairPadLaunchDeployer` initializes it. Alternatively, clearly communicate this centralized control to all users and `originalDeployer`s.

StatusUnresolved

Low

Potential Gas Limit Issues for `initGuardList` with Large Lists

L-01The `initGuardList` function iterates through an array of addresses provided by `IGuardConfig(factory).guardListOf`. If this array contains an extremely large number of addresses, the transaction to initialize the guard list could exceed the block gas limit, causing the transaction to revert. This would prevent the guard list from being fully set, potentially leaving the token in an unexpected state regarding its transfer restrictions (7.2 Code Security, 7.8 Operations).

IssueThe `initGuardList` function iterates through an array of addresses provided by `IGuardConfig(factory).guardListOf`. If this array contains an extremely large number of addresses, the transaction to initialize the guard list could exceed the block gas limit, causing the transaction to revert. This would prevent the guard list from being fully set, potentially leaving the token in an unexpected state regarding its transfer restrictions (7.2 Code Security, 7.8 Operations).

FixImplement a maximum practical limit on the size of the `list` array that can be passed to `initGuardList` within the `IGuardConfig` implementation or `PairPadLaunchDeployer`. Alternatively, consider a batched approach for adding allowed addresses if very large lists are anticipated, though this would require design changes to `initGuardList`.

StatusUnresolved

Low

Metadata String Length Limits Only Enforced at Deployment

L-02The `PairPadLaunchDeployer` contract enforces `MAX_NAME_LENGTH`, `MAX_SYMBOL_LENGTH`, etc., for metadata fields during the `deployToken` function. While this prevents excessively long strings from being stored during initial deployment, the `PairPadLauncherToken` itself does not have any setter functions for these metadata fields. If the design were to change to allow updates, the lack of length checks within the token contract itself could become an issue. Given the current immutable design, this is a minor observation (7.2 Code Security).

IssueThe `PairPadLaunchDeployer` contract enforces `MAX_NAME_LENGTH`, `MAX_SYMBOL_LENGTH`, etc., for metadata fields during the `deployToken` function. While this prevents excessively long strings from being stored during initial deployment, the `PairPadLauncherToken` itself does not have any setter functions for these metadata fields. If the design were to change to allow updates, the lack of length checks within the token contract itself could become an issue. Given the current immutable design, this is a minor observation (7.2 Code Security).

FixNo action required for the current design. If future upgrades introduce mutable metadata fields, ensure that appropriate length validation is implemented within the setter functions in the `PairPadLauncherToken` contract.

StatusUnresolved

Info

Short Guard Window Duration

I-01The `MAX_GUARD_SECONDS` constant is set to 60 seconds. This means the 'launch guard' mechanism, which restricts transfers for non-allowed recipients, is active for a very short period. While this might be intentional for rapid token launches, it significantly limits the practical utility of the guard for preventing sustained bot activity or large-scale dumping beyond the immediate launch minute (7.4 Economic).

IssueThe `MAX_GUARD_SECONDS` constant is set to 60 seconds. This means the 'launch guard' mechanism, which restricts transfers for non-allowed recipients, is active for a very short period. While this might be intentional for rapid token launches, it significantly limits the practical utility of the guard for preventing sustained bot activity or large-scale dumping beyond the immediate launch minute (7.4 Economic).

FixConfirm that a 60-second guard window aligns with the intended security and economic strategy for token launches. If longer protection is desired, the `MAX_GUARD_SECONDS` constant would need to be increased, along with a re-evaluation of its implications.

StatusUnresolved

Info

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

I-02The `owner()` function, commonly found in OpenZeppelin's `Ownable` contracts or similar access control patterns, is explicitly overridden in `PairPadLauncherToken` to always return `address(0)`. This indicates a deliberate design choice for the token to have no single administrative owner after deployment, relying on the `creator` (PairPadLaunchDeployer) for `initGuardList` and the immutability of other parameters (7.3 Access Control).

IssueThe `owner()` function, commonly found in OpenZeppelin's `Ownable` contracts or similar access control patterns, is explicitly overridden in `PairPadLauncherToken` to always return `address(0)`. This indicates a deliberate design choice for the token to have no single administrative owner after deployment, relying on the `creator` (PairPadLaunchDeployer) for `initGuardList` and the immutability of other parameters (7.3 Access Control).

FixNo action required, as this appears to be an intentional design decision. Ensure this characteristic is clearly documented for users and developers to avoid confusion regarding token ownership and administrative capabilities.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The technical architecture (7.1) is straightforward, utilizing a factory pattern for token deployment. Code security (7.2) is generally good, with OpenZeppelin standards for ERC20 and ERC20Burnable, and no apparent reentrancy or integer overflow vulnerabilities. Access control (7.3) is well-defined: `PairPadLaunchDeployer` uses an `onlyFactory` modifier, and `PairPadLauncherToken` restricts `initGuardList` to its `creator` (which is the `PairPadLaunchDeployer`). Immutable variables enhance security by preventing critical parameter changes post-deployment. String manipulation for metadata generation, while complex, is confined to view functions, mitigating transaction gas risks.

GovernanceMedium5/10

The economic model (7.4) centers on a standard ERC20 token with a temporary launch guard. The guard's maximum duration is 60 seconds, limiting its long-term impact on token economics. Governance (7.5) is highly centralized during the token's initial setup phase. The `PairPadLaunchDeployer` contract, and by extension its `factory` (via `IGuardConfig`), holds significant control over the initial guard list configuration for newly deployed tokens. This critical dependency on the `factory` for guard parameters introduces a substantial trust assumption, as a compromised `factory` could manipulate the guard mechanism.

UpgradesLow9/10

The contracts are not designed to be upgradeable (7.7), as no proxy patterns or upgrade mechanisms are implemented. This eliminates upgrade-related risks but means any future changes would require a new deployment.

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

23.2% in top 10

9.8% in wallets13.4% in contracts

Effective Concentration15.2%

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

$97.4K across 2 pairs

Uniswap v4ETHanalysed$96.1K Uniswap v4USDC$1.3K

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

0x99f4…336c

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

7 factors

Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
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
1 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 crucial to thoroughly audit and secure the `factory` contract that implements the `IGuardConfig` interface, as its integrity directly impacts the security of all deployed `PairPadLauncherToken` instances.…

Read the verdictHide

Consider implementing a mechanism for the `originalDeployer` to review or approve the guard list before it is initialized by the `PairPadLaunchDeployer`, if direct control is desired. Additionally, evaluate the practical implications of the 60-second guard window and the potential for gas limit issues with extremely large guard lists, although the latter is a low probability given typical list sizes.

Contract

TypePairPadLauncherToken

Audit History

1 audit on record

Sep 1225

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

Not Signed In

Is Fuse a Scam?

Security Findings

Critical Dependency on `IGuardConfig` Implementation

Centralized Control over Guard List Initialization

Potential Gas Limit Issues for `initGuardList` with Large Lists

Metadata String Length Limits Only Enforced at Deployment

Short Guard Window Duration

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

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?