Quantum Audit Logo

Is Cortex Safe?

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

Cortex CX
0x0000…6033
Base
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.
Last checked 5d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Cortex (CX) token contract is an ERC-20 token with interchain capabilities, built upon OpenZeppelin standards and custom interchain application logic. The contract exhibits a robust technical foundation, leveraging audited OpenZeppelin libraries and Solidity 0.8.24 for built-in overflow/underflow protection. However, the design incorporates significant centralized control over token supply and transfer mechanisms, managed by specific roles. Furthermore, its interchain functionality introduces dependencies on external clients and requires careful operational management of transaction fees. While no critical vulnerabilities were identified, the high degree of centralized power and external dependencies warrant careful consideration.

1 High2 Medium1 Low1 Informational
Volume 24h
$1.86M
Liquidity
$385.3K
Price
$0.03334
Token Age
1y
Top 10 Holders
101.6%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control Over Token Supply and Transfers

H-01The `GOVERNANCE_ROLE` possesses significant power, including the ability to `toggleAllowList`, `enableTransfers` (which can halt all transfers for non-allowlisted users), and `burnAllocation` from any account. The `MINTER_ROLE` can `mint` an unlimited supply of tokens. This high degree of centralization (7.3 Access Control, 7.5 Governance) means that a single compromised key or malicious actor holding these roles could lead to severe economic manipulation, including arbitrary token burning, unlimited inflation, or a complete denial of service for token transfers (7.4 Economic).
IssueThe `GOVERNANCE_ROLE` possesses significant power, including the ability to `toggleAllowList`, `enableTransfers` (which can halt all transfers for non-allowlisted users), and `burnAllocation` from any account. The `MINTER_ROLE` can `mint` an unlimited supply of tokens. This high degree of centralization (7.3 Access Control, 7.5 Governance) means that a single compromised key or malicious actor holding these roles could lead to severe economic manipulation, including arbitrary token burning, unlimited inflation, or a complete denial of service for token transfers (7.4 Economic).
FixImplement a robust multi-signature wallet for the `GOVERNANCE_ROLE` and `MINTER_ROLE` with a high threshold of required signers. Consider implementing time-locks for critical administrative actions to provide a window for community review or emergency intervention. Clearly document the responsibilities and operational procedures for these roles.
StatusUnresolved
Medium

Operational Risk for Interchain Messaging Fees

M-01The `_sendInterchainMessage` function requires the contract to hold sufficient native tokens (e.g., ETH on Ethereum, MATIC on Polygon) to cover the `messageFee` for outgoing interchain transactions. If the contract's native token balance falls below the required fee, interchain messages cannot be sent, leading to a denial of service for interchain functionality (7.8 Operations). This requires continuous operational oversight to ensure the contract is adequately funded.
IssueThe `_sendInterchainMessage` function requires the contract to hold sufficient native tokens (e.g., ETH on Ethereum, MATIC on Polygon) to cover the `messageFee` for outgoing interchain transactions. If the contract's native token balance falls below the required fee, interchain messages cannot be sent, leading to a denial of service for interchain functionality (7.8 Operations). This requires continuous operational oversight to ensure the contract is adequately funded.
FixEstablish a clear operational procedure for monitoring and topping up the contract's native token balance. Consider implementing a mechanism for authorized parties to deposit native tokens into the contract specifically for interchain fees, or integrate with a treasury management system. Implement alerts for low native token balances.
StatusUnresolved
Medium

Dependency on External Interchain Client Security

M-02The `AbstractICApp` contract, and by extension `CX`, relies heavily on an external `IInterchainClientV1` for all interchain communication, including sending and receiving messages, and calculating fees. The security and integrity of this external client are paramount (7.6 External). Any vulnerability, compromise, or malicious behavior within the `IInterchainClientV1` implementation could directly impact the `CX` token's interchain functionality, potentially leading to loss of funds, incorrect message routing, or a complete halt of interchain operations.
IssueThe `AbstractICApp` contract, and by extension `CX`, relies heavily on an external `IInterchainClientV1` for all interchain communication, including sending and receiving messages, and calculating fees. The security and integrity of this external client are paramount (7.6 External). Any vulnerability, compromise, or malicious behavior within the `IInterchainClientV1` implementation could directly impact the `CX` token's interchain functionality, potentially leading to loss of funds, incorrect message routing, or a complete halt of interchain operations.
FixConduct thorough due diligence on the `IInterchainClientV1` contract, including reviewing its audit reports, security practices, and operational history. Implement robust monitoring for all interactions with the interchain client. Consider a mechanism to update or replace the interchain client in case of a critical vulnerability or compromise, if the architecture allows.
StatusUnresolved
Low

Lack of Granular Pause/Unpause for Interchain App

L-01While the `_transfersEnabled` flag provides a mechanism to control token transfers, there isn't a separate, explicit pause/unpause mechanism specifically for the interchain application functionality (e.g., `appReceive`, `_sendInterchainMessage`). In an emergency related to the interchain client or network, a more granular control to temporarily halt interchain operations without affecting local token transfers might be beneficial (7.8 Operations).
IssueWhile the `_transfersEnabled` flag provides a mechanism to control token transfers, there isn't a separate, explicit pause/unpause mechanism specifically for the interchain application functionality (e.g., `appReceive`, `_sendInterchainMessage`). In an emergency related to the interchain client or network, a more granular control to temporarily halt interchain operations without affecting local token transfers might be beneficial (7.8 Operations).
FixConsider adding a separate `_interchainEnabled` flag or a similar pausing mechanism specifically for interchain operations, controlled by the `GOVERNANCE_ROLE`. This would allow for more targeted emergency responses without impacting the core ERC-20 transfer functionality.
StatusUnresolved
Info

Complex Inheritance Structure

I-01The `CX` contract inherits from multiple OpenZeppelin contracts (`ERC20Burnable`, `ERC20Permit`, `ERC20Votes`) and custom base contracts (`CXEvents`, `InterchainToken`, `AbstractICApp`). This complex inheritance hierarchy (7.1 Architecture) increases the overall complexity of the codebase and the potential for subtle interaction bugs or unexpected behavior, despite the robustness of OpenZeppelin libraries.
IssueThe `CX` contract inherits from multiple OpenZeppelin contracts (`ERC20Burnable`, `ERC20Permit`, `ERC20Votes`) and custom base contracts (`CXEvents`, `InterchainToken`, `AbstractICApp`). This complex inheritance hierarchy (7.1 Architecture) increases the overall complexity of the codebase and the potential for subtle interaction bugs or unexpected behavior, despite the robustness of OpenZeppelin libraries.
FixEnsure comprehensive unit and integration tests cover all inherited functionalities and custom overrides, especially focusing on interactions between different base contracts. Maintain clear documentation of the inheritance hierarchy and function override logic to aid future development and auditing efforts.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical implementation (7.2 Code Security) benefits from using Solidity 0.8.24, which includes default overflow/underflow checks, and extensive reliance on battle-tested OpenZeppelin contracts, reducing common attack vectors like reentrancy. The contract's architecture (7.1 Architecture) integrates ERC-20, voting, and interchain functionalities, which adds complexity. A key technical risk is the dependency on an external interchain client (7.6 External), whose security is critical for the protocol's interchain operations.

GovernanceHigh1/10

The contract's economic model (7.4 Economic) and governance structure (7.5 Governance) are highly centralized. The `GOVERNANCE_ROLE` has extensive control, including the ability to toggle an allowlist, enable/disable all transfers, and burn tokens from any account. The `MINTER_ROLE` can mint an unlimited supply of tokens. This concentration of power (7.3 Access Control) means that a compromise of these roles could lead to significant economic manipulation or a denial of service for token holders.

UpgradesHigh3/10

The provided contract code (7.7 Upgrades) does not implement any explicit proxy or upgradeability patterns. Therefore, the contract is assumed to be non-upgradeable, which eliminates upgrade-specific risks but means any future changes would require a new deployment and migration.

Security Checklist

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

Liquidity Depth

$385.5K across 3 pairs
AerodromeWETHanalysed$385.3K100.0%AerodromeWETH$1740.0%Hydrex CLAMMWETH$180.0%

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

Key Addresses

6 addresses
Deployer
0x6fd8…9e7f
Unlocked LP Held By
0xaf6d…6f4d0xb29e…99720x3dd5…599d0xe911…09f30xfb53…326c

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (101.6% total → 64.2% effective; 39.2% in EOAs, 62.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.7% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 2 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
Wrapped PROS (PROS)Critical RiskChipCritical Riskdefi-nativeCritical RiskXRP (Universal) (UXRP)Critical RiskVCATCritical RiskThe White Wolf (WOLF)Critical Risk

Would You Like a More Detailed Audit of Cortex?

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

Get Detailed Audit