Quantum Audit Logo

Is Clearpool Safe?

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

Is this your token? Publish your own audit on this page →

Clearpool CPOOL
0x6676…fac5
Ethereum
Not verifiedThis 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 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Clearpool (CPOOL) token contract is a standard ERC-20 implementation with added Compound-style delegation features. The contract demonstrates robust security practices, including custom safe math for `uint96` and `uint32` types, and proper EIP-712 signature handling for delegation. No critical or high-severity vulnerabilities were identified. Minor informational and low-severity findings relate to design choices and best practices.

2 Low2 Informational
Volume 24h
$396.8K
Liquidity
$74.1K
Price
$0.02497
Token Age
1y
Top 10 Holders
51.9%

Security Findings

2 Low2 Info
Low

Initial Centralization of Total Supply

L-01In the constructor, the entire `totalSupply` (1 billion tokens) is minted and assigned to a single `multisig` address. This means that at deployment, 100% of the token supply is controlled by this single address. While common for initial token distribution, it represents a significant point of centralization and control over the token's initial liquidity and distribution strategy.
IssueIn the constructor, the entire `totalSupply` (1 billion tokens) is minted and assigned to a single `multisig` address. This means that at deployment, 100% of the token supply is controlled by this single address. While common for initial token distribution, it represents a significant point of centralization and control over the token's initial liquidity and distribution strategy.
FixEnsure the `multisig` address is secured with robust operational procedures, including strong key management, multi-factor authentication, and a sufficient number of signers. Clearly communicate the role and security measures of this `multisig` to the community. This is a standard practice, but its security is paramount.
StatusUnresolved
Low

Potential for High Gas Costs in `getPriorVotes` with Many Checkpoints

L-02The `getPriorVotes` function uses a binary search algorithm to find historical vote counts. While efficient for sorted data, if a delegatee accumulates an extremely large number of checkpoints (e.g., one per block over many years), the gas cost for accessing and iterating through the `checkpoints` mapping could become substantial. Although `numCheckpoints` is limited by `uint32`, practical gas limits might be hit before reaching the theoretical maximum, potentially leading to denial of service for this specific function for highly active delegatees.
IssueThe `getPriorVotes` function uses a binary search algorithm to find historical vote counts. While efficient for sorted data, if a delegatee accumulates an extremely large number of checkpoints (e.g., one per block over many years), the gas cost for accessing and iterating through the `checkpoints` mapping could become substantial. Although `numCheckpoints` is limited by `uint32`, practical gas limits might be hit before reaching the theoretical maximum, potentially leading to denial of service for this specific function for highly active delegatees.
FixMonitor the gas usage of `getPriorVotes` in production, especially for delegatees with a high number of checkpoints. While the current implementation is standard and generally efficient, consider if any edge cases could lead to prohibitive gas costs. No immediate code change is required, but awareness and monitoring are advised.
StatusUnresolved
Info

Use of `uint96` for Core Balances and Votes

I-01The contract utilizes `uint96` for `balances`, `allowances`, and `votes` storage variables. This design choice is typically made to optimize gas usage by fitting values into smaller storage slots. However, it limits the maximum possible value for these quantities to `2^96 - 1`, which is approximately 7.92 x 10^28. While this is a very large number, it is smaller than the maximum value of `uint256`.
IssueThe contract utilizes `uint96` for `balances`, `allowances`, and `votes` storage variables. This design choice is typically made to optimize gas usage by fitting values into smaller storage slots. However, it limits the maximum possible value for these quantities to `2^96 - 1`, which is approximately 7.92 x 10^28. While this is a very large number, it is smaller than the maximum value of `uint256`.
FixEnsure that all users and integrators are aware of the `uint96` limit for token balances and voting power. This is a design decision, and no direct action is required if the limit is acceptable for the protocol's long-term scale. Document this constraint clearly in external-facing documentation.
StatusUnresolved
Info

`getChainId()` Implementation Using Assembly

I-02The `getChainId()` function uses inline assembly (`assembly { chainId := chainid() }`) to retrieve the chain ID. While functional and common in older Solidity versions, Solidity 0.8.0 and later (which this contract uses) provide the `block.chainid` global variable, offering a more readable and safer way to access the chain ID without resorting to assembly.
IssueThe `getChainId()` function uses inline assembly (`assembly { chainId := chainid() }`) to retrieve the chain ID. While functional and common in older Solidity versions, Solidity 0.8.0 and later (which this contract uses) provide the `block.chainid` global variable, offering a more readable and safer way to access the chain ID without resorting to assembly.
FixReplace the assembly block in `getChainId()` with `return block.chainid;` for improved code clarity and to leverage native Solidity features. This is a minor best practice improvement.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The CPOOL contract exhibits strong technical security. It implements custom `safe96`, `safe32`, `add96`, and `sub96` functions to prevent integer overflows and underflows, which is a significant strength (7.2 Code Security). The delegation mechanism correctly utilizes EIP-712 signatures with nonces and expiry to prevent replay attacks. Access control (7.3 Access Control) is decentralized, with no privileged roles beyond the initial token distribution. A minor point is the use of `assembly { chainId := chainid() }` instead of `block.chainid` for Solidity 0.8.4+.

GovernanceHigh2/10

The contract defines a fixed total supply of 1 billion CPOOL tokens, with initial distribution entirely to a specified multisig address (7.4 Economic). This initial centralization is a common practice but represents a single point of control for the initial token supply (7.5 Governance). The token incorporates Compound-style delegation, allowing holders to delegate their voting power, which is a robust and widely adopted governance primitive. No direct economic exploits were identified within the token's core functionality.

UpgradesMedium6/10

The CPOOL contract is deployed as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates upgrade-related risks such as proxy implementation vulnerabilities or administrative key compromises, but also means the contract's logic cannot be modified post-deployment. This provides immutability and predictability for users.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

51.9% in top 10
42.0% in wallets9.9% in contracts
Effective Concentration46.0%

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

$128.9K across 4 pairs
Uniswap v3USDCanalysed$74.1K57.5%Uniswap v4ETH$40.7K31.6%Uniswap v4USDT$13.3K10.4%Uniswap v3USDC$7400.6%

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
0xc40e…6946
Unlocked LP Held By
0x9b81…7db9

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (51.9% total → 46.0% effective; 42.0% in EOAs, 9.9% 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, pool = 58% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 58% of DEX liquidity)
  • 2 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
ADIMedium RiskTakoMedium RiskRenzo (REZ)Medium RiskInjective (INJ)Medium RiskLighter (LIT)Medium RiskAaveMedium Risk

Would You Like a More Detailed Audit of Clearpool?

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

Get Detailed Audit