Quantum Audit Logo

Is Checkmate Safe?

On-chain security analysis — is it a scam or legit?

Checkmate CHECK
0x9126…86eb
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The ERC20FixedSupply contract implements a standard fixed-supply ERC-20 token with additional features like batch transfers, permit functionality, token recovery, and meta-transaction support. The contract utilizes a modular architecture with library-based storage. No critical vulnerabilities were identified, but centralized ownership and potential front-running in permit functions are noted.

1 Medium1 Low2 Informational
Volume 24h
$73.6K
Liquidity
$28.9K
Price
$0.01307
Token Age
1y
Top 10 Holders
91.4%

Security Findings

1 Med1 Low2 Info
Medium

Centralized Ownership

M-01The `ContractOwnership` pattern grants significant control to a single owner address, including the ability to transfer ownership and potentially recover tokens via `TokenRecovery`. This introduces a single point of failure, where compromise of the owner's private key could lead to unauthorized control over critical contract functions.
IssueThe `ContractOwnership` pattern grants significant control to a single owner address, including the ability to transfer ownership and potentially recover tokens via `TokenRecovery`. This introduces a single point of failure, where compromise of the owner's private key could lead to unauthorized control over critical contract functions.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract owner to distribute control and reduce the risk of a single point of failure. For highly sensitive operations, explore time-locked transactions or a more decentralized governance mechanism.
StatusUnresolved
Low

Potential Front-Running in ERC20Permit

L-01The `permit` function, while adhering to the EIP-2612 standard, can be susceptible to front-running attacks. An attacker observing a signed `permit` message could execute the `transferFrom` before the legitimate user, potentially leading to unexpected transaction ordering or a 'sandwich attack' if the `deadline` is set too far in the future or not used effectively.
IssueThe `permit` function, while adhering to the EIP-2612 standard, can be susceptible to front-running attacks. An attacker observing a signed `permit` message could execute the `transferFrom` before the legitimate user, potentially leading to unexpected transaction ordering or a 'sandwich attack' if the `deadline` is set too far in the future or not used effectively.
FixUsers should be advised to set a reasonable and short `deadline` for `permit` signatures to minimize the window for front-running. Developers should ensure the `ERC20Permit` implementation correctly validates `deadline` and `nonce` to prevent replay attacks.
StatusUnresolved
Info

Storage Layout Pattern for Non-Upgradeable Contract

I-01The contract utilizes a storage layout pattern (e.g., `Layout` structs, `LAYOUT_STORAGE_SLOT`, `PROXY_INIT_PHASE_SLOT`) typically found in upgradeable proxy implementation contracts. While this contract is not explicitly a proxy, this design choice might be confusing or lead to issues if it were later used as an implementation without proper proxy setup, potentially causing storage collisions or unexpected behavior.
IssueThe contract utilizes a storage layout pattern (e.g., `Layout` structs, `LAYOUT_STORAGE_SLOT`, `PROXY_INIT_PHASE_SLOT`) typically found in upgradeable proxy implementation contracts. While this contract is not explicitly a proxy, this design choice might be confusing or lead to issues if it were later used as an implementation without proper proxy setup, potentially causing storage collisions or unexpected behavior.
FixClarify in documentation whether this contract is intended to be used as a standalone token or as an implementation for a proxy. If standalone, consider simplifying storage management if the proxy-specific patterns are not strictly necessary. If it is intended for future proxy use, ensure the proxy setup is robust and compatible with this storage pattern.
StatusUnresolved
Info

Dependency on External Forwarder Registry

I-02The `ForwarderRegistryContext` relies on an external `IForwarderRegistry` for meta-transaction functionality. The security and trustworthiness of this external registry are critical for the proper and secure operation of meta-transactions within this token contract. Any compromise or malfunction of the registry could impact the ability to process meta-transactions.
IssueThe `ForwarderRegistryContext` relies on an external `IForwarderRegistry` for meta-transaction functionality. The security and trustworthiness of this external registry are critical for the proper and secure operation of meta-transactions within this token contract. Any compromise or malfunction of the registry could impact the ability to process meta-transactions.
FixEnsure the `IForwarderRegistry` contract is thoroughly audited, well-maintained, and controlled by a secure, preferably decentralized, entity. Document the expected behavior and security considerations of the forwarder registry for users and integrators.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates a robust modular architecture, leveraging multiple OpenZeppelin-style extensions for ERC-20 functionality (7.1 Architecture). It includes features like safe transfers, batch transfers, and meta-transaction support, enhancing usability and security (7.2 Code Security). Access control is managed via `ContractOwnership`, ensuring only the designated owner can perform privileged actions like `transferOwnership` (7.3 Access Control). However, the reliance on a single owner introduces a centralization risk.

GovernanceHigh1/10

The economic model is a fixed-supply ERC-20 token, with all tokens minted during construction, preventing inflationary risks post-deployment (7.4 Economic). Governance is centralized, with a single owner controlling critical functions such as `transferOwnership` and potentially `TokenRecovery` (7.5 Governance). This centralization means the project's security heavily depends on the owner's integrity and operational security.

UpgradesMedium6/10

The contract is not designed as an upgradeable proxy, as indicated by `is_proxy: false`. However, it employs storage layout patterns (e.g., `Layout` structs, `LAYOUT_STORAGE_SLOT`, `PROXY_INIT_PHASE_SLOT`) commonly associated with upgradeable contracts (7.7 Upgrades). While this doesn't pose a direct vulnerability for a standalone contract, it could lead to confusion or issues if the contract were mistakenly used as an implementation for a proxy without proper setup.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

91.4% in top 10
14.8% in wallets76.7% in contracts
Effective Concentration45.4%

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.8K across 10 pairs
AerodromeUSDCanalysed$28.9K87.9%AerodromeUSDC$2.7K8.2%AerodromeTOWER$1.1K3.3%AerodromeMOCA$1230.4%Uniswap v4USDC$280.1%AerodromeAERO$230.1%
Show 4 more pairsShow less
Uniswap v4USDC$80.0%Uniswap v4ETH$70.0%Uniswap v4USDC$30.0%PancakeswapWETH$20.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 Holder92.7%
Top-3 Unlocked98.1%

Key Addresses

7 addresses
Deployer
0x9de1…8bdb
Unlocked LP Held By
0xcc2b…49070x73fc…1ee50x75d7…5f1d0x5c3b…25af0x9211…61b70x9b05…520a

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 30% (91.4% total → 45.4% effective; 14.8% in EOAs, 76.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($32,820 across 10 pairs — thin market)
  • LP top1 unlocked holder = 92.7% (independent LP — depth risk, pool = 88% of DEX liquidity)
  • LP top3 unlocked holders = 98.1% (independent LP — depth risk, pool = 88% of DEX liquidity)
  • 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

Related Audits

6 more on the record
AUTONOMOPOLY (AUTONO)High RiskSolana (SOL)High RiskTAOTHigh RiskSoSoValue (SOSO)High RiskSally (A1C)High RiskHOMEHigh Risk

Would You Like a More Detailed Audit of Checkmate?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit