Is c8ntinuum (CTM) a Scam? Security Analysis

Rug Pull Risk Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2259Jul 2349

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalLow

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

GovernanceHigh

3/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 add

UpgradesHigh

3/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 flexibi

LP Distribution

Top-1 Unlocked Holder45.6%

Top-3 Unlocked100.0%

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

Security Findings

4 total

1 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

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 `0x70F279Fa72c82110A0bB4745D6283B790190c33F`. 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.

Recommendation: 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.

M-01MediumUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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.

Recommendation: 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.

I-01InformationalUnresolved

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.

Recommendation: 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.

Is c8ntinuum a Scam? CTM