Quantum Audit Logo

Is Cluster Protocol Safe?

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

Cluster Protocol CP
0x001a…3f77
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Informational
Volume 24h
$6.12M
Liquidity
$923.0K
Price
$0.03762
Token Age
1y
Top 10 Holders
88.6%

Security Findings

1 High1 Med1 Info
High

Centralized Control of Critical Roles

H-01The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Medium

Potential for Miner Manipulation of Timestamps in Authorization

M-01The `_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).
IssueThe `_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).
FixEnsure 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.
StatusUnresolved
Info

Unused `_ccipAdmin` Variable

I-01The `_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).
IssueThe `_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).
FixClearly 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh1/10

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

UpgradesHigh3/10

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

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

88.6% in top 10
1.7% in wallets87.0% in contracts
Effective Concentration36.5%

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

$923.4K across 5 pairs
AerodromeUSDCanalysed$923.0K100.0%Uniswap v4ETH$1890.0%Uniswap v4USDC$1040.0%Uniswap v4USDC$1010.0%Uniswap v4USDC$190.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x9db9…1ee2
Unlocked LP Held By
0x0b23…1b14

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 (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

Related Audits

6 more on the record
ether.fi governance token (ETHFI)High RiskResearchCoin (RSC)High RiskFren PetHigh RiskBaseStonk (BSTONK)High RiskVoice of the Gods by Virtuals (ADM)High RiskWrapped State Street SPDR Portfolio S&P 500 ETF ST0x (WTSPYM)High Risk

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