Quantum Audit Logo

Is c8ntinuum a Scam?

Honeypot, rug-pull and ownership checks

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

c8ntinuum CTM
0xc8fb…8888
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The CTM contract is an ERC20 token implementation utilizing OpenZeppelin's AccessControl for role management. The contract features a fixed maximum supply and a minter role. Key findings include a high centralization risk due to a single hardcoded address controlling all administrative and minting capabilities, which presents a single point of failure. The code itself is straightforward and leverages well-audited OpenZeppelin libraries, minimizing technical vulnerabilities.

1 High1 Medium1 Low1 Informational
i Our automated scanner reviewed c8ntinuum (CTM) on Ethereum. 2 of 5 security checks passed — see the full breakdown below.
Volume 24h
$2.57M
Liquidity
$2.61M
Price
$0.2302
Age
3mo
Top 10 Holders
15.3%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Critical Roles

H-01The `DEFAULT_ADMIN_ROLE` and `MINTER_ROLE` are initially granted to a single hardcoded External Owned Account (EOA) at address 0x70F2…c33F. This creates a single point of failure for the contract's access control (7.3 Access Control) and economic stability (7.4 Economic). If this EOA's private key is compromised, an attacker would gain full control over role management (granting/revoking any role) and token minting, potentially minting tokens up to the `MAX_SUPPLY` and devaluing existing tokens.
IssueThe `DEFAULT_ADMIN_ROLE` and `MINTER_ROLE` are initially granted to a single hardcoded External Owned Account (EOA) at address . This creates a single point of failure for the contract's access control (7.3 Access Control) and economic stability (7.4 Economic). If this EOA's private key is compromised, an attacker would gain full control over role management (granting/revoking any role) and token minting, potentially minting tokens up to the `MAX_SUPPLY` and devaluing existing tokens.
FixIt is strongly recommended to transfer the `DEFAULT_ADMIN_ROLE` and `MINTER_ROLE` to a multi-signature wallet (e.g., Gnosis Safe) immediately after deployment. This distributes control and requires multiple approvals for critical operations, significantly reducing the risk associated with a single point of failure.
StatusUnresolved
Medium

Hardcoded `DEFAULT_ADMIN` Address

M-01The `DEFAULT_ADMIN` address is hardcoded in the contract's constructor. While this sets the initial administrator, it means that if the project wishes to change the primary administrator or if the initial admin key is lost/compromised, there is no direct on-chain mechanism to replace this initial address without the current admin's cooperation (7.8 Operations). This creates an operational dependency on a specific, immutable address.
IssueThe `DEFAULT_ADMIN` address is hardcoded in the contract's constructor. While this sets the initial administrator, it means that if the project wishes to change the primary administrator or if the initial admin key is lost/compromised, there is no direct on-chain mechanism to replace this initial address without the current admin's cooperation (7.8 Operations). This creates an operational dependency on a specific, immutable address.
FixWhile `AccessControl` allows the current admin to `grantRole` to a new address, it is crucial to have a robust operational procedure for managing this key. For future deployments or if the project matures, consider a more flexible or decentralized approach for initial admin assignment, or at least a well-defined process for transferring this critical role to a new, secure entity.
StatusUnresolved
Low

Lack of Upgradeability

L-01The `CTM` contract is not implemented with an upgradeable proxy pattern (7.7 Upgrades). This design choice means that any future bug fixes, feature enhancements, or changes to the token's logic would require deploying an entirely new contract and migrating all token holders and liquidity. This can be a complex, costly, and disruptive process for the community.
IssueThe `CTM` contract is not implemented with an upgradeable proxy pattern (7.7 Upgrades). This design choice means that any future bug fixes, feature enhancements, or changes to the token's logic would require deploying an entirely new contract and migrating all token holders and liquidity. This can be a complex, costly, and disruptive process for the community.
FixIf future flexibility and adaptability are desired, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) for the token contract. If non-upgradeability is an intentional design choice for immutability, ensure all current logic is thoroughly audited and tested to minimize the need for future changes.
StatusUnresolved
Info

Centralized Minting Authority

I-01The `MINTER_ROLE` has the exclusive authority to mint new `CTM` tokens up to the `MAX_SUPPLY` (7.4 Economic). This design introduces a centralized point of control over the token supply. While common for initial token distribution or specific tokenomics models, it means the token's value is highly dependent on the integrity and security of the `MINTER_ROLE` holder.
IssueThe `MINTER_ROLE` has the exclusive authority to mint new `CTM` tokens up to the `MAX_SUPPLY` (7.4 Economic). This design introduces a centralized point of control over the token supply. While common for initial token distribution or specific tokenomics models, it means the token's value is highly dependent on the integrity and security of the `MINTER_ROLE` holder.
FixClearly communicate the implications of centralized minting to token holders and the community. If the project intends to move towards decentralization, consider a roadmap for revoking the `MINTER_ROLE` or transitioning to a community-governed minting mechanism in the future. Ensure the `MINTER_ROLE` is secured with best practices, such as a multi-signature wallet.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The CTM contract (7.1 Architecture) is a standard ERC20 token with minting and burning functionality, built upon OpenZeppelin's secure libraries. The custom logic for minting includes a check against MAX_SUPPLY, preventing over-minting (7.2 Code Security). Access control (7.3 Access Control) is implemented using OpenZeppelin's AccessControl, which is robust. However, the reliance on a single EOA for all critical roles introduces a significant technical risk.

GovernanceHigh3/10

The economic model (7.4 Economic) of CTM features a fixed maximum supply and a centralized minting authority. The `MINTER_ROLE` and `DEFAULT_ADMIN_ROLE` are controlled by a single hardcoded address, creating a significant centralization risk. This single point of failure means compromise of this address could lead to unauthorized minting up to the maximum supply, severely impacting token value. There is no on-chain governance (7.5 Governance) mechanism, centralizing all decision-making with the initial admin.

UpgradesHigh3/10

The CTM contract is not designed with an upgradeability pattern (7.7 Upgrades). This means that any future changes, bug fixes, or feature additions would necessitate a new contract deployment and a potentially complex token migration process. While this ensures immutability, it limits future flexibility. This is a design choice, not a vulnerability, but impacts long-term adaptability.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

15.3% in top 10
12.0% in wallets3.2% in contracts
Effective Concentration13.3%

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

$2.62M across 2 pairs
Uniswap v4ETHanalysed$2.61M99.6%Uniswap v4USDT$9.4K0.4%

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 Holder47.8%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xbb84…8a70
Unlocked LP Held By
0xd5fa…25d90x9e20…348a0xcc81…c042

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

What Raised This Score

7 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 High finding(s) from audit
  • 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
Curve DAO (CRV)High RiskFrax USD (FRXUSD)High RiskEthena (ENA)High RiskEigenCloud (prev. EigenLayer) (EIGEN)High RiskCapHigh RiskYield Basis (YB)High Risk

Would You Like a More Detailed Audit of c8ntinuum?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit