Quantum Audit Logo
Launch App

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

Is Cluster Protocol Safe?

CPBase
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades3/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Info3
SummaryAI Copilot

The CPToken contract implements an ERC20 token with additional features like ERC20Permit and a custom authorization mechanism for transfers and receives.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (88.6% total → 36.5% effective; 1.7% in EOAs, 87.0% in contracts — moderate)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 Medium 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
87.0%Contracts1.7%11.4%Everyone else
87.0%Contracts11.4%
ContractsWalletsEveryone elseBubble area = share of supply
88.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking87.0%
  • Walletsanonymous holders, free to sell1.7%
  • Everyone elsethe rest of the supply11.4%
Effective concentrationwhat the score reads36.5%
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$923.4K across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$923.0KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x0b23…1b14

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

Security Findings

1 High1 Medium1 Info
High

Centralized Control of Critical Roles

The DEFAULT_ADMIN_ROLE holds significant power within the CPToken contract. This role is responsible for granting MINTER_ROLE and BURNER_ROLE, and for setting the _ccipAdmin address. If this role is controlled by a single External Owned Account (EOA), it represents a single point of failure. A compromised or malicious administrator could mint tokens up to MAX_SUPPLY, burn tokens from any account that has granted an allowance to the BURNER_ROLE holder, and potentially influence cross-chain operations via the _ccipAdmin (if it's used externally). This centralization poses a high risk to the protocol's security and economic stability (7.3 Access Control, 7.5 Governance).H-01

Issue

The DEFAULT_ADMIN_ROLE holds significant power within the CPToken contract. This role is responsible for granting MINTER_ROLE and BURNER_ROLE, and for setting the _ccipAdmin address. If this role is controlled by a single External Owned Account (EOA), it represents a single point of failure. A compromised or malicious administrator could mint tokens up to MAX_SUPPLY, burn tokens from any account that has granted an allowance to the BURNER_ROLE holder, and potentially influence cross-chain operations via the _ccipAdmin (if it's used externally). This centralization poses a high risk to the protocol's security and economic stability (7.3 Access Control, 7.5 Governance).

Fix

Implement a multi-signature wallet or a robust governance mechanism (e.g., DAO) to control the DEFAULT_ADMIN_ROLE. This will distribute administrative power and reduce the risk associated with a single point of failure.

Status

Unresolved

Medium

Potential for Miner Manipulation of Timestamps in Authorization

The _requireValidAuthorization function, used by transferWithAuthorization and receiveWithAuthorization, relies on block.timestamp to enforce validAfter and validBefore conditions. While block.timestamp is a standard practice, it can be manipulated by miners within a certain range (up to 900 seconds on Ethereum). If the validAfter/validBefore window is very narrow (e.g., a few blocks), a miner could potentially front-run or delay a transaction to cause it to fail due to timestamp expiry or prematurity, even if the user intended it to be valid. This could lead to user frustration or failed transactions (7.2 Code Security).M-01

Issue

The _requireValidAuthorization function, used by transferWithAuthorization and receiveWithAuthorization, relies on block.timestamp to enforce validAfter and validBefore conditions. While block.timestamp is a standard practice, it can be manipulated by miners within a certain range (up to 900 seconds on Ethereum). If the validAfter/validBefore window is very narrow (e.g., a few blocks), a miner could potentially front-run or delay a transaction to cause it to fail due to timestamp expiry or prematurity, even if the user intended it to be valid. This could lead to user frustration or failed transactions (7.2 Code Security).

Fix

Ensure that the validAfter and validBefore windows are sufficiently wide (e.g., several hours or days) to mitigate the impact of miner timestamp manipulation. Users should be made aware of this characteristic when generating signed authorizations.

Status

Unresolved

Info

Unused _ccipAdmin Variable

The _ccipAdmin state variable is declared, initialized in the constructor, and has a setter function (setCCIPAdmin) restricted to DEFAULT_ADMIN_ROLE, along with a getter. However, no other logic within the CPToken contract directly utilizes this variable. This suggests it might be a placeholder for future functionality or integration with an external CCIP system. Without its intended use, it represents an incomplete feature or dead code within the current contract scope, potentially leading to confusion or an unnecessary attack surface if its external purpose is not well-defined (7.1 Architecture, 7.2 Code Security).I-01

Issue

The _ccipAdmin state variable is declared, initialized in the constructor, and has a setter function (setCCIPAdmin) restricted to DEFAULT_ADMIN_ROLE, along with a getter. However, no other logic within the CPToken contract directly utilizes this variable. This suggests it might be a placeholder for future functionality or integration with an external CCIP system. Without its intended use, it represents an incomplete feature or dead code within the current contract scope, potentially leading to confusion or an unnecessary attack surface if its external purpose is not well-defined (7.1 Architecture, 7.2 Code Security).

Fix

Clearly document the intended purpose and usage of the _ccipAdmin variable. If it's for future integration, ensure that the external system's security is thoroughly reviewed once implemented. If it's not intended for use, consider removing it to reduce contract complexity and improve clarity.

Status

Unresolved

Analysis

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

The CPToken contract implements an ERC20 token with additional features like ERC20Permit and a custom authorization mechanism for transfers and receives. It utilizes OpenZeppelin's AccessControl for role-based permissions, including MINTER_ROLE and BURNER_ROLE, and enforces a MAX_SUPPLY. The contract demonstrates good adherence to established standards and includes robust checks for authorization validity and signature verification. However, the centralized nature of the DEFAULT_ADMIN_ROLE poses a significant single point of failure, and the reliance on block.timestamp for authorization validity introduces a minor risk of miner manipulation. An unused _ccipAdmin variable also suggests potential for incomplete features or lack of clarity.

Technical6/10Medium risk

The CPToken contract is built upon well-audited OpenZeppelin libraries for ERC20, ERC20Permit, and AccessControl, contributing to a solid technical foundation (7.2 Code Security). The custom authorization mechanism, including transferWithAuthorization and receiveWithAuthorization, is implemented with careful checks for signature validity, nonce usage, and time windows, effectively preventing replay attacks (7.2 Code Security). However, the reliance on block.timestamp for authorization validity introduces a minor risk of miner manipulation if time windows are narrow (7.2 Code Security). Additionally, the _ccipAdmin variable is declared but unused within the contract, indicating a potential for incomplete features or unclear architectural intent (7.1 Architecture).

Governance1/10High risk

The contract establishes a clear role-based access control system with DEFAULT_ADMIN_ROLE, MINTER_ROLE, and BURNER_ROLE, ensuring controlled token supply management and privileged operations (7.3 Access Control). A MAX_SUPPLY is enforced, preventing arbitrary inflation beyond a defined limit (7.4 Economic). However, the DEFAULT_ADMIN_ROLE holds significant power, including the ability to grant minting and burning capabilities and manage the _ccipAdmin (7.5 Governance). If this role is controlled by a single entity, it represents a centralized point of failure, posing a high risk to the protocol's security and economic stability (7.5 Governance).

Upgrades3/10High risk

The CPToken contract is implemented as a standard, non-upgradeable ERC20 token. This design choice simplifies the deployment and reduces the complexity associated with upgrade mechanisms, such as proxy patterns, thereby eliminating potential upgrade-related vulnerabilities (7.7 Upgrades). However, it also means that any future bug fixes, feature enhancements, or changes to the token's logic would require a new deployment and migration of assets, which can be a complex and costly process for users and the protocol (7.7 Upgrades).

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the CPToken protocol, it is strongly recommended to implement a robust multi-signature wallet or a decentralized autonomous organization (DAO) to control the DEFAULT_ADMIN_ROLE.

This measure will distribute administrative power, mitigate the risk of a single point of failure, and improve the overall trust model. Additionally, ensure that the validAfter and validBefore parameters for signed authorizations are set with sufficiently wide time windows to minimize the impact of potential miner timestamp manipulation. Finally, clarify and document the intended purpose of the _ccipAdmin variable to ensure transparency and prepare for any future integrations.

Contract & Record

1 audit on record
TypeCPToken
NetworkBase
Token age1y
Contract0x001a…3f77
Deployer0x9db9…1ee2
Badge for your website
Cluster Protocol 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 3, 202665High

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

Frequently Asked Questions

What is the CP contract address?

The Cluster Protocol (CP) contract on Base is 0x001aad84c21a5cd4d696c56d44866e9703c43f77. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Cluster Protocol a scam?

Quantum Audit's risk score for Cluster Protocol is 65/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is CP liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $923.4K.

Who holds CP?

As of Sep 4, 2026, the 10 largest holders own 88.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
ether.fi governance tokenETHFI · Base65HighWorldMobileTokenWMTX · Base65HighApple 3x LongAAPLX3L · Base65HighNoahBase65HighResearchCoinRSC · Base66HighFren PetBase66High

Would You Like a More Detailed Audit of Cluster Protocol?

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

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