Is Slap Cat (SLAP) a Scam? Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Missing `_disableInitializers()` in Constructor of Upgradeable Contract

H-01The `TokenV2` contract is an upgradeable implementation designed to be deployed behind a proxy. It correctly uses an `initialize` function with the `initializer` modifier. However, its constructor is empty and does not call `_disableInitializers()`. If this implementation contract is ever deployed directly (not through a proxy), its `initialize` function could be called multiple times by anyone, leading to re-initialization of state variables and potential exploits, such as re-minting tokens or changing critical parameters.

IssueThe `TokenV2` contract is an upgradeable implementation designed to be deployed behind a proxy. It correctly uses an `initialize` function with the `initializer` modifier. However, its constructor is empty and does not call `_disableInitializers()`. If this implementation contract is ever deployed directly (not through a proxy), its `initialize` function could be called multiple times by anyone, leading to re-initialization of state variables and potential exploits, such as re-minting tokens or changing critical parameters.

FixAdd `_disableInitializers()` to the constructor of the `TokenV2` contract. This prevents the `initialize` function from being called on the implementation contract directly, mitigating the risk of re-initialization.

StatusUnresolved

Medium

Centralized Control over Transfer Constraints

M-01The `transferConstraints` mechanism, which restricts token transfers to or from specified Uniswap V2 and V3 pools, can be entirely removed by the contract owner via the `removeTransferConstraints()` function. This grants significant centralized control to a single entity, allowing them to unilaterally alter a core token transfer behavior that could impact liquidity or trading strategies.

IssueThe `transferConstraints` mechanism, which restricts token transfers to or from specified Uniswap V2 and V3 pools, can be entirely removed by the contract owner via the `removeTransferConstraints()` function. This grants significant centralized control to a single entity, allowing them to unilaterally alter a core token transfer behavior that could impact liquidity or trading strategies.

FixConsider implementing a multi-signature wallet or a time-locked governance mechanism for critical functions like `removeTransferConstraints()`. This would distribute control, increase transparency, and provide a delay for community review before significant changes are enacted.

StatusUnresolved

Low

Single Point of Failure for Owner Role

L-01The contract relies on a single `owner` address for critical administrative functions, such as `removeTransferConstraints()`. If the owner's private key is compromised, or the owner becomes malicious, the protocol could be at risk of unauthorized changes or manipulation.

IssueThe contract relies on a single `owner` address for critical administrative functions, such as `removeTransferConstraints()`. If the owner's private key is compromised, or the owner becomes malicious, the protocol could be at risk of unauthorized changes or manipulation.

FixImplement a multi-signature wallet for the owner role to distribute control and enhance security. This requires multiple trusted parties to approve transactions, significantly reducing the risk associated with a single point of failure.

StatusUnresolved

Info

All Tokens Minted to Initializer

I-01During the `initialize` function call, the entire `maxSupply` of tokens is minted to `msg.sender` (the address that calls `initialize`). This design choice means the deployer or the address responsible for initialization will initially hold the entire token supply.

IssueDuring the `initialize` function call, the entire `maxSupply` of tokens is minted to `msg.sender` (the address that calls `initialize`). This design choice means the deployer or the address responsible for initialization will initially hold the entire token supply.

FixEnsure that the address performing the initialization is a secure, controlled entity (e.g., a multi-sig wallet or a trusted contract) and that this initial distribution model aligns with the project's intended tokenomics and distribution strategy. Clearly communicate this distribution to stakeholders.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages well-audited OpenZeppelin Upgradeable libraries for ERC20, ERC20Permit, and Ownable functionalities, contributing to a strong foundation (7.2 Code Security). The custom `_beforeTokenTransfer` logic for `transferConstraints` is straightforward and does not introduce reentrancy or complex external calls. However, a significant technical risk is the omission of `_disableInitializers()` in the constructor, which could allow re-initialization if the implementation contract is directly deployed (7.7 Upgrades).

GovernanceMedium4/10

The contract design grants the owner significant control, particularly over the `transferConstraints` mechanism, which can be unilaterally removed (7.3 Access Control). This centralized control introduces a single point of failure risk (7.5 Governance). Economically, the entire `maxSupply` is minted to the initializer, which is a design choice that centralizes initial token distribution (7.4 Economic).

UpgradesHigh3/10

The contract is designed as an upgradeable implementation using OpenZeppelin's `Upgradeable` pattern, which is a standard and generally secure approach (7.1 Architecture). The `initialize` function correctly uses the `initializer` modifier. However, the absence of `_disableInitializers()` in the constructor of the implementation contract poses a high risk, as it could allow for multiple initializations if the implementation is ever called directly (7.7 Upgrades).

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

100.0% in top 10

0.0% in wallets100.0% in contracts

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

$37.7K across 2 pairs

Pancakeswap v3WBNBanalysed$37.7K UniswapUSDT$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.

Key Addresses

1 addresses

Deployer

0x01db…d845

What Raised This Score

9 factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 30% (100.0% total → 40.0% effective; 0.0% in EOAs, 100.0% in contracts — moderate)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
Liquidity < $50k ($37,741 across 2 pairs — thin market)
Token age < 30 days (still settling)
1 High finding(s) from audit
1 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

Is Slap Cat a Scam?

Security Findings

Missing `_disableInitializers()` in Constructor of Upgradeable Contract

Centralized Control over Transfer Constraints

Single Point of Failure for Owner Role

All Tokens Minted to Initializer

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Slap Cat?