Is Keyboard Cat (KEYCAT) a Scam? Security Analysis

Security Findings

3 Low3 Info

Low

Potential for Centralized Control over Supply (if custom mint/burn exists)

L-01While the provided OpenZeppelin base code has internal `_mint` and `_burn` functions, the specific `KeyboardCat` contract implementation was not provided. If the `KeyboardCat` contract exposes these functions to a single owner or a small set of privileged addresses, it introduces a centralized point of control over the token supply, which could be a concern for decentralization.

IssueWhile the provided OpenZeppelin base code has internal `_mint` and `_burn` functions, the specific `KeyboardCat` contract implementation was not provided. If the `KeyboardCat` contract exposes these functions to a single owner or a small set of privileged addresses, it introduces a centralized point of control over the token supply, which could be a concern for decentralization.

FixIf `_mint` or `_burn` functions are exposed, consider implementing a multi-signature wallet for their execution or integrating them into a decentralized governance mechanism to mitigate centralization risks.

StatusUnresolved

Low

Lack of Pausability Mechanism

L-02The current ERC20 implementation does not include a pausability mechanism. In certain scenarios, such as critical vulnerabilities discovered in integrated protocols or during emergency upgrades, the ability to pause token transfers can be crucial to prevent further damage or loss of funds.

IssueThe current ERC20 implementation does not include a pausability mechanism. In certain scenarios, such as critical vulnerabilities discovered in integrated protocols or during emergency upgrades, the ability to pause token transfers can be crucial to prevent further damage or loss of funds.

FixConsider integrating OpenZeppelin's `Pausable` module if the token is part of a complex ecosystem where emergency halts might be necessary. This should be controlled by a robust access control mechanism (e.g., a multi-sig or governance).

StatusUnresolved

Low

No Emergency Token Recovery Mechanism

L-03The contract lacks a function to recover accidentally sent ERC-20 tokens (other than the token itself) or native currency (ETH/Base) that might be mistakenly sent to the contract address. Such assets would become permanently locked.

IssueThe contract lacks a function to recover accidentally sent ERC-20 tokens (other than the token itself) or native currency (ETH/Base) that might be mistakenly sent to the contract address. Such assets would become permanently locked.

FixImplement a function, callable by a trusted role (e.g., owner or multi-sig), to recover arbitrary ERC-20 tokens and native currency sent to the contract. This can prevent loss of funds due to user error.

StatusUnresolved

Info

Adherence to ERC-20 Standard and OpenZeppelin Best Practices

I-01The contract strictly adheres to the ERC-20 standard and utilizes battle-tested OpenZeppelin contracts (version 5.0.2). This includes robust implementations for `transfer`, `transferFrom`, `approve`, and `permit` functionalities, inheriting security features and best practices from a widely audited codebase.

IssueThe contract strictly adheres to the ERC-20 standard and utilizes battle-tested OpenZeppelin contracts (version 5.0.2). This includes robust implementations for `transfer`, `transferFrom`, `approve`, and `permit` functionalities, inheriting security features and best practices from a widely audited codebase.

FixContinue to rely on well-established and audited libraries for core functionalities. Regularly monitor OpenZeppelin security advisories for any updates or patches.

StatusResolved

Info

Efficient Gas Usage with `unchecked` Blocks

I-02The contract uses `unchecked` blocks for arithmetic operations (e.g., `_balances[from] = fromBalance - value;`) where prior checks ensure that underflow or overflow cannot occur. For instance, `fromBalance < value` is checked before subtraction. This practice optimizes gas consumption without compromising security.

IssueThe contract uses `unchecked` blocks for arithmetic operations (e.g., `_balances[from] = fromBalance - value;`) where prior checks ensure that underflow or overflow cannot occur. For instance, `fromBalance < value` is checked before subtraction. This practice optimizes gas consumption without compromising security.

FixMaintain the current approach of using `unchecked` blocks judiciously, only when the safety of the operation is guaranteed by preceding checks, to ensure gas efficiency.

StatusResolved

Info

ERC-20 Permit Functionality

I-03The contract includes ERC-20 Permit functionality, allowing users to approve token transfers via a signed message rather than an on-chain transaction. This enhances user experience by enabling gasless approvals and can be beneficial for integrations with other protocols.

IssueThe contract includes ERC-20 Permit functionality, allowing users to approve token transfers via a signed message rather than an on-chain transaction. This enhances user experience by enabling gasless approvals and can be beneficial for integrations with other protocols.

FixEnsure off-chain systems handling permit signatures are robust and prevent replay attacks by correctly managing nonces and deadlines. Educate users on the security implications of signing messages.

StatusResolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is robust, leveraging battle-tested OpenZeppelin contracts for ERC20 and ERC20Permit functionality. Code security (7.2) is high, with proper use of `unchecked` blocks for gas optimization in arithmetic operations where overflows/underflows are prevented by prior checks, such as in `_update` for balance adjustments. Access control (7.3) is standard for an ERC20 token, relying on `_msgSender()` for transfer and approval operations. No reentrancy or other common EVM vulnerabilities were identified in the provided code.

GovernanceMedium5/10

The economic model (7.4) is that of a standard ERC20 token, facilitating basic transfers and approvals. No complex economic incentives or mechanisms are present in the provided base contracts. Governance (7.5) is minimal, as the token itself does not include specific governance features. Any centralized control over token supply (e.g., minting/burning) would depend on the specific implementation of the `KeyboardCat` contract, which was not provided. External (7.6) interactions are limited to standard ERC20 interfaces.

UpgradesLow7/10

The provided contract is not designed as an upgradeable proxy (7.7), as indicated by `is_proxy: false` in the prefill. Therefore, upgrade safety concerns are not applicable to this specific deployment. This simplifies the deployment model and removes a common source of complexity and potential vulnerabilities associated with upgradeable contracts. Operations (7.8) are straightforward, involving standard token management.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

45.5% in top 10

39.6% in wallets5.9% in contracts

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

$1.06M across 16 pairs

Uniswap v2WETHanalysed$974.6K Uniswap v3WETH$29.6K AerodromeWETH$24.7K Uniswap v2VIRTUAL$24.4K Uniswap v4AIOCTO$7.7K Uniswap v3USDC$1.1K

Show 4 more pairsShow less

Uniswap v4ETH$112 Uniswap v3TOSHI$111 Hydrex CLAMMUSDC$99 Uniswap v4ETH$58

The 6 remaining pairs hold $24 between them and are not listed.

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%

Key Addresses

10 addresses

Deployer

0x4993…5afe

Unlocked LP Held By

0x694e…00db0x1a96…45550x2af8…70250x6d6a…19550xb3ac…68a00xc188…47f20xba92…8ff00x65b0…e4650x4985…2b2b

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

What Raised This Score

3 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (45.5% total → 42.0% effective; 39.6% in EOAs, 5.9% in contracts — moderate)
3 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 Keyboard Cat a Scam?

Security Findings

Potential for Centralized Control over Supply (if custom mint/burn exists)

Lack of Pausability Mechanism

No Emergency Token Recovery Mechanism

Adherence to ERC-20 Standard and OpenZeppelin Best Practices

Efficient Gas Usage with `unchecked` Blocks

ERC-20 Permit Functionality

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