Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is c8ntinuum a Scam?

CTMEthereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance3/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The CTM contract is an ERC20 token implementation utilizing OpenZeppelin's AccessControl for role management.

Read the full analysis
What raised the score
  • Ownership not renounced
  • 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%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Our automated scanner reviewed c8ntinuum (CTM) on Ethereum. 2 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
3.2%12.0%Wallets84.7%Everyone else
12.0%84.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
15.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking3.2%
  • Walletsanonymous holders, free to sell12.0%
  • Everyone elsethe rest of the supply84.7%
Effective concentrationwhat the score reads13.3%
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$2.62M across 2 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$2.61MShare of depth99.6%
Top-1 Unlocked Holder47.8%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control of Critical Roles

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Hardcoded DEFAULT_ADMIN Address

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Lack of Upgradeability

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Centralized Minting Authority

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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.

Governance3/10High risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize securing the DEFAULT_ADMIN address by transitioning it to a robust multi-signature wallet.

This will mitigate the single point of failure risk for both administrative and minting roles. Establish clear operational procedures for managing this critical address and for any future role transfers. Consider the long-term implications of centralized minting and communicate this clearly to token holders, potentially outlining a path towards decentralization if aligned with project goals.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age3mo
Contract0xc8fb…8888
Deployer0xbb84…8a70
Badge for your website
c8ntinuum 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. Jul 23, 202649Medium
  2. Jul 22, 202659Medium

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

Related Audits

6 more on the recordAll audits
Curve DAOCRV · Ethereum49MediumFrax USDFRXUSD · Ethereum49MediumAdsharesADS · Ethereum49MediumDestra NetworkDSYNC · Ethereum49MediumAlchemixALCX · Ethereum49MediumFortaFORT · Ethereum49Medium

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 Is this your token? Publish your own audit on this page