First Protocol logoFirst Protocol
EVIDENCE COMES FIRST
CP
PROJECT / 001

Cluster Protocol

Sources reviewed: 27–28 Sep 2026Source-code review · 27 Sep 2026
Original FLS #001 · v0.1

Historical launch score

FLS #001 · v0.1 · reviewed 14 Sep 2026

Historical score · Reviewed 14 Sep 2026

Corrected on 1 Oct 2026

Historical score uses v0.1. Current framework: FLS Methodology v0.2

74/100
Corrected

Correction · 1 Oct 2026

Original wording
“no admin controls”
Corrected finding
The reviewed contract includes role administration.
Reason
The later source review identified role-based administrative control in the reviewed contract.

Historical score: 74/100 · Original FLS #001 · v0.1 · Reviewed 14 Sep 2026. This correction does not recalculate the score. Any potential score impact requires a separate dated reassessment.

Every correction has a history.

What is claimed. What is established.
Five topics, supporting evidence and research history.
CLAIMS · PILOT
Tap a check to explore →
Supply015 billion CPPer-contract capPARTIAL↗Mint authority02Via MINTER_ROLEWithin the supply capSOURCE CHECKED↗Contract control03Role administrationCurrent holders unresolvedPARTIAL↗Liquidity lock04Not establishedLP / locker evidence neededEVIDENCE NEEDED↗Team allocation0517% disclosedWallet mapping not confirmedPROJECT DISCLOSURE↗
Status describes evidence completeness. Amber text highlights material powers.

Evidence & Findings

The preserved research is available below without running scripts. If buttons are inactive, download the HTML and open it in a browser for network checks. Empty readings do not establish absence of permissions.

Open findings and evidence ↓

Preserved research · FIRST-CP-001

What does the 5 billion cap establish?

Project statement: A fixed maximum of 5 billion CP across supported chains.

FIRST finding: The reviewed contract caps its own supply at 5 billion CP. A global cross-chain cap is not established by this check.

Review scope: The code enforces a per-contract limit. Global cross-chain conservation requires separate pool and configuration checks.

Evidence and next verification step

src/CPToken.sol · 40–41

    uint256 public constant MAX_SUPPLY = 5_000_000_000 * 1e18;

src/CPToken.sol · 136–142

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        if (totalSupply() + amount > MAX_SUPPLY) {
            revert MaxSupplyExceeded(totalSupply() + amount);
        }
        _mint(to, amount);
    }

src/CPToken.sol · 92–110

    constructor(
        address _treasury,
        address _admin,
        uint256 _initialSupply
    ) ERC20("Cluster Protocol", "CP") ERC20Permit("Cluster Protocol") {
        require(_admin != address(0), "admin cannot be zero");
        require(_initialSupply <= MAX_SUPPLY, "exceeds max supply");

        _grantRole(DEFAULT_ADMIN_ROLE, _admin);
        _ccipAdmin = _admin;

        if (_initialSupply > 0 && _treasury != address(0)) {
            _mint(_treasury, _initialSupply);
        }
    }

    // ═══════════════════════════════════════════════════════════════
    //                   CCIP CCT INTERFACE
    // ═══════════════════════════════════════════════════════════════

Identify minters and inspect their cross-chain controls.

Project disclosure

Sourcify sources

Can more tokens be minted?

Project statement: Cross-chain transfers use CCIP burn-and-mint.

FIRST finding: Yes. A MINTER_ROLE holder can mint while this contract’s totalSupply stays within 5 billion CP. Minting is not disabled.

Review scope: The code enforces a per-contract limit. Global cross-chain conservation requires separate pool and configuration checks.

Evidence and next verification step

src/CPToken.sol · 40–41

    uint256 public constant MAX_SUPPLY = 5_000_000_000 * 1e18;

src/CPToken.sol · 136–142

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        if (totalSupply() + amount > MAX_SUPPLY) {
            revert MaxSupplyExceeded(totalSupply() + amount);
        }
        _mint(to, amount);
    }

src/CPToken.sol · 92–110

    constructor(
        address _treasury,
        address _admin,
        uint256 _initialSupply
    ) ERC20("Cluster Protocol", "CP") ERC20Permit("Cluster Protocol") {
        require(_admin != address(0), "admin cannot be zero");
        require(_initialSupply <= MAX_SUPPLY, "exceeds max supply");

        _grantRole(DEFAULT_ADMIN_ROLE, _admin);
        _ccipAdmin = _admin;

        if (_initialSupply > 0 && _treasury != address(0)) {
            _mint(_treasury, _initialSupply);
        }
    }

    // ═══════════════════════════════════════════════════════════════
    //                   CCIP CCT INTERFACE
    // ═══════════════════════════════════════════════════════════════

Identify minters and inspect their cross-chain controls.

Project disclosure

Sourcify sources

Who can change the rules?

Project statement: A fixed non-proxy token with role-based administration.

FIRST finding: Roles can be assigned by the administrator. No token upgrade or administrative freeze/seizure path was identified in the reviewed source. Current role holders remain unresolved.

Review scope: Limited source review backed by the registry’s exact-match report. No independent recompilation or fresh runtime comparison was completed in this research session.

Evidence and next verification step

src/CPToken.sol · 126–130

    function grantMintAndBurnRoles(address pool) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _grantRole(MINTER_ROLE, pool);
        _grantRole(BURNER_ROLE, pool);
    }

lib/openzeppelin-contracts/contracts/access/AccessControl.sol · 122–125

    function grantRole(bytes32 role, address account) public virtual onlyRole(getRoleAdmin(role)) {
        _grantRole(role, account);
    }

src/CPToken.sol · 27–39

contract CPToken is ERC20, ERC20Permit, AccessControl {

    // ═══════════════════════════════════════════════════════════════
    //                          ROLES
    // ═══════════════════════════════════════════════════════════════

    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");

    // ═══════════════════════════════════════════════════════════════
    //                        CONSTANTS
    // ═══════════════════════════════════════════════════════════════

Read RoleGranted / RoleRevoked from deployment, replay changes and check hasRole at one finalized block.

Project disclosure

Sourcify sources

Is liquidity locked?

Project statement: No specific lock statement has been selected for verification yet.

FIRST finding: No lock has been verified in this research. This is not a finding that liquidity is unlocked.

Review scope: No complete pool, position or locker analysis has been performed.

Evidence and next verification step

Technical evidence has not yet been collected.

Identify pools and LP owners, then examine lock amount, expiry and withdrawal powers.

Project disclosure

What is known about the team allocation?

Project statement: Team allocation: 17%; initial team unlock: 0%.

FIRST finding: The published allocation is 17%. We have not independently verified the wallet mapping or its on-chain execution.

Review scope: A disclosed allocation is not a measurement of current holdings or proof of all related wallets.

Evidence and next verification step

Technical evidence has not yet been collected.

Map disclosed team and investor wallets, inspect vesting and distinguish allocation from current balances.

Project disclosure

FLS #001: historical score 74/100, reviewed 14 Sep 2026 using v0.1. Corrected on 1 Oct 2026: the reviewed contract includes role administration. The score has not been reassessed.

Check details, snapshot history and review request

Snapshots and drafts are stored only in this browser. Export an archive to preserve them. Requests are not sent anywhere.

Sources / history / methodology

Project history in FIRST
14.09.2026

Initial FLS #001 review: 74/100 under methodology v0.1.

27.09.2026

Source review preserved: six technical claims with references and open questions.

01.10.2026

Correction · “no admin controls” → role administration. Status: Corrected. Historical FLS #001 score 74/100 is unchanged.

Behind the findings

AI-assisted source review. Sourcify reports an exact contract match. Independent auditing and verification of current role holders are still outstanding.

Sourcify · preserved source evidence · Project disclosure

Historical score uses v0.1. Current framework: FLS Methodology v0.2

FLS #001 · v0.1

Historical launch score

Corrected on 1 Oct 2026

Corrected on 1 Oct 2026: the reviewed contract includes role administration. Historical score 74/100 is unchanged. Any score impact requires a separate dated reassessment.

Original FLS 001 CP scorecard, 74 out of 100, reviewed September 14 2026