Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Keyboard Cat a Scam?

KEYCATBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance5/10Upgrades7/10Checks passed4 of 5Findings3 Low · 3 Info6
SummaryAI Copilot

This audit covers the provided Solidity source code, which consists of standard OpenZeppelin ERC20 and ERC20Permit implementations (version 5.0.2).

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 30%
  • 3 Low finding(s) from audit
Exact 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

Our automated scanner reviewed Keyboard Cat (KEYCAT) on Base. 4 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
5.9%39.6%Wallets54.5%Everyone else
5.9%39.6%Wallets54.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
45.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.9%
  • Walletsanonymous holders, free to sell39.6%
  • Everyone elsethe rest of the supply54.5%
Effective concentrationwhat the score reads42.0%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.06M across 16 pairs
Show 4 more pairs

The 6 remaining pairs hold $24 between them and are not listed. The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$974.6KShare of depth91.7%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0%
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.

Security Findings

3 Low3 Info
Low

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

While 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.L-01

Issue

While 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.

Fix

If _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.

Status

Unresolved

Low

Lack of Pausability Mechanism

The 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.L-02

Issue

The 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.

Fix

Consider 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).

Status

Unresolved

Low

No Emergency Token Recovery Mechanism

The 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.L-03

Issue

The 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.

Fix

Implement 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.

Status

Unresolved

Info

Adherence to ERC-20 Standard and OpenZeppelin Best Practices

The 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.I-01

Issue

The 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.

Fix

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

Status

Resolved

Info

Efficient Gas Usage with unchecked Blocks

The 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.I-02

Issue

The 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.

Fix

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

Status

Resolved

Info

ERC-20 Permit Functionality

The 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.I-03

Issue

The 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.

Fix

Ensure 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.

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

This audit covers the provided Solidity source code, which consists of standard OpenZeppelin ERC20 and ERC20Permit implementations (version 5.0.2). The specific KeyboardCat contract logic was not provided, so the assessment focuses on the inherent security of the OpenZeppelin base contracts. These libraries are widely used and battle-tested, contributing to a low overall risk profile. The audit identifies no critical or high-severity vulnerabilities within the provided code.

Technical10/10Low risk

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.

Governance5/10Medium risk

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.

Upgrades7/10Low risk

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.

Final RecommendationWhat to do about this score

It is recommended to conduct thorough integration testing if this token is to be used within a larger DeFi ecosystem, ensuring compatibility and correct interaction with other protocols.

Consider implementing additional features like pausability or an emergency token recovery mechanism if the token's role in the ecosystem warrants such controls. Finally, ensure that any custom logic added to the KeyboardCat contract (beyond the OpenZeppelin base) undergoes a separate, detailed security review.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2y
Contract0x9a26…7973
Deployer0x4993…5afe
Badge for your website
Keyboard Cat security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 20261Low
  2. Aug 16, 20263Low

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

Related Audits

6 more on the recordAll audits
Unit 00 - ReiREI · Base0LowMr. MigglesMIGGLES · Base0LowBrettBase0Lowmfercoin$MFER · Base3LowdoginmeBase3LowToshiBase5Low

Would You Like a More Detailed Audit of Keyboard Cat?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page