Is Covalent X Token (CXT) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Low2 Info

High

Centralized Control of Minting Cap

H-01The `updateMintCap` function, controlled by the `CAP_MANAGER_ROLE`, allows setting `mintPerSecondCap` to any `uint256` value without an upper bound. If the address holding `CAP_MANAGER_ROLE` is compromised, an attacker could set an extremely high or infinite minting cap, effectively removing all emission controls and leading to arbitrary token inflation. This poses a severe economic risk to the token's value.

IssueThe `updateMintCap` function, controlled by the `CAP_MANAGER_ROLE`, allows setting `mintPerSecondCap` to any `uint256` value without an upper bound. If the address holding `CAP_MANAGER_ROLE` is compromised, an attacker could set an extremely high or infinite minting cap, effectively removing all emission controls and leading to arbitrary token inflation. This poses a severe economic risk to the token's value.

FixImplement a multi-signature wallet for the `CAP_MANAGER_ROLE` to distribute control. Consider adding a maximum allowable value for `mintPerSecondCap` or a time-locked delay for significant cap increases to provide a window for community review or emergency intervention.

StatusUnresolved

High

High Power of DEFAULT_ADMIN_ROLE

H-02The `protocolCouncil` address is granted the `DEFAULT_ADMIN_ROLE` in the constructor. This role has the power to grant and revoke any other role, including itself. This creates a single point of failure where compromise of the `protocolCouncil` address would grant an attacker complete control over all access control mechanisms, including minting, cap management, and Permit2 allowance toggling.

IssueThe `protocolCouncil` address is granted the `DEFAULT_ADMIN_ROLE` in the constructor. This role has the power to grant and revoke any other role, including itself. This creates a single point of failure where compromise of the `protocolCouncil` address would grant an attacker complete control over all access control mechanisms, including minting, cap management, and Permit2 allowance toggling.

FixAssign the `DEFAULT_ADMIN_ROLE` to a robust multi-signature wallet with a high number of required confirmations. This significantly reduces the risk of a single compromised key leading to full protocol takeover. Regularly review and audit the signers of this multi-sig.

StatusUnresolved

Medium

Miner Manipulability of `block.timestamp` for Minting

M-01The `mint` function calculates `maxMint` based on `block.timestamp - lastMint`. While `block.timestamp` is generally reliable, miners have a limited ability to manipulate it (e.g., up to 900 seconds on Ethereum) to slightly increase the `timeElapsedSinceLastMint` and thus the `maxMint` amount within a block. Although the impact might be minor given the `mintPerSecondCap`, a malicious miner could potentially front-run or manipulate block timestamps to mint slightly more tokens than intended.

IssueThe `mint` function calculates `maxMint` based on `block.timestamp - lastMint`. While `block.timestamp` is generally reliable, miners have a limited ability to manipulate it (e.g., up to 900 seconds on Ethereum) to slightly increase the `timeElapsedSinceLastMint` and thus the `maxMint` amount within a block. Although the impact might be minor given the `mintPerSecondCap`, a malicious miner could potentially front-run or manipulate block timestamps to mint slightly more tokens than intended.

FixWhile `block.timestamp` is a common and generally accepted practice for time-based calculations, for highly sensitive operations like token minting, consider if an alternative time source (e.g., an oracle for time) or a mechanism that averages `block.timestamp` over several blocks could further reduce this risk, if deemed necessary. For this specific use case, the risk is mitigated by the `mintPerSecondCap` and `lastMint` update.

StatusUnresolved

Low

Missing Zero Address Check for `emissionManager` in Constructor

L-01The constructor explicitly checks if `migration`, `protocolCouncil`, or `emergencyCouncil` are `address(0)` and reverts with `InvalidAddress`. However, there is no such check for the `emissionManager` address. While `_grantRole` would likely revert if `emissionManager` is `address(0)`, an explicit check improves clarity and consistency.

IssueThe constructor explicitly checks if `migration`, `protocolCouncil`, or `emergencyCouncil` are `address(0)` and reverts with `InvalidAddress`. However, there is no such check for the `emissionManager` address. While `_grantRole` would likely revert if `emissionManager` is `address(0)`, an explicit check improves clarity and consistency.

FixAdd an explicit `require(emissionManager != address(0), "InvalidAddress")` check for the `emissionManager` parameter in the constructor to ensure all critical role addresses are valid.

StatusUnresolved

Info

Non-Upgradeable Contract

I-01The CovalentXToken contract is deployed as a standard implementation contract and is not designed with an upgradeable proxy pattern. This means that once deployed, its logic cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's economic model would necessitate deploying an entirely new contract and migrating existing token holders.

IssueThe CovalentXToken contract is deployed as a standard implementation contract and is not designed with an upgradeable proxy pattern. This means that once deployed, its logic cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's economic model would necessitate deploying an entirely new contract and migrating existing token holders.

FixAcknowledge the implications of non-upgradeability. For future contracts, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent) if flexibility for future changes is desired. Ensure thorough testing and auditing of the current non-upgradeable contract to minimize the need for future redeployments.

StatusUnresolved

Info

Permit2 Default Max Approval

I-02The contract grants `type(uint256).max` allowance to the hardcoded Permit2 address by default if `permit2Enabled` is true. While this is a common pattern for Permit2 integration to simplify user experience, it delegates significant trust to the Permit2 contract itself. If a vulnerability were to be discovered in Permit2, or if the `PERMIT2_REVOKER_ROLE` were compromised, it could lead to unauthorized token transfers.

IssueThe contract grants `type(uint256).max` allowance to the hardcoded Permit2 address by default if `permit2Enabled` is true. While this is a common pattern for Permit2 integration to simplify user experience, it delegates significant trust to the Permit2 contract itself. If a vulnerability were to be discovered in Permit2, or if the `PERMIT2_REVOKER_ROLE` were compromised, it could lead to unauthorized token transfers.

FixEnsure the `PERMIT2_REVOKER_ROLE` is secured with a multi-signature wallet. Regularly monitor the security landscape of the Permit2 contract and be prepared to disable the integration via `updatePermit2Allowance(false)` if any critical vulnerabilities are identified in Permit2.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good technical architecture (7.1) by utilizing battle-tested OpenZeppelin libraries for ERC20 and AccessControl functionalities, enhancing code security (7.2). The minting logic correctly uses `block.timestamp` and updates `lastMint` to prevent re-entry issues within the same block. However, the reliance on `block.timestamp` for `maxMint` calculation introduces a minor risk of miner manipulation (7.2). The Permit2 integration is well-implemented, providing a revocable default max approval.

GovernanceHigh2/10

The economic model (7.4) is highly dependent on the security of the `EMISSION_ROLE` and `CAP_MANAGER_ROLE`, as these control token supply and emission limits. The governance model (7.5) is centralized, with the `protocolCouncil` holding the `DEFAULT_ADMIN_ROLE`, `CAP_MANAGER_ROLE`, and `PERMIT2_REVOKER_ROLE`. This concentration of power means a compromise of the `protocolCouncil` address could lead to unlimited token minting via `updateMintCap` (H-01) or full control over all roles (H-02), posing a significant economic risk to token holders. The initial mint of 1 billion tokens to a `migration` address is a critical operational (7.8) decision.

UpgradesMedium4/10

The CovalentXToken contract is not designed to be upgradeable (7.7). This means that any future changes, bug fixes, or feature additions would require a complete redeployment of the contract and a migration of existing token holders. While this eliminates risks associated with proxy upgrade mechanisms, it introduces inflexibility for future protocol evolution.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

Holder Composition

56.0% in top 10

12.2% in wallets43.8% in contracts

Effective Concentration29.8%

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

$52.5K

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.6%

Top-3 Unlocked99.9%

Key Addresses

5 addresses

Deployer

0xebba…652a

Unlocked LP Held By

0x220b…e57e0xf385…5f850xebfc…291d0xcf8e…2520

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 > 20% (56.0% total → 29.8% effective; 12.2% in EOAs, 43.8% in contracts — mild)
LP top1 unlocked holder = 99.6% (independent LP — depth risk)
LP top3 unlocked holders = 99.9% (independent LP — depth risk)
LP claimed locked but only 0.0% actually locked
2 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

Final Recommendation

AI Copilot

To mitigate the identified risks, it is strongly recommended to implement robust security measures for the addresses holding critical roles, especially the `DEFAULT_ADMIN_ROLE` and `CAP_MANAGER_ROLE`.…

Read the verdictHide

Consider using a multi-signature wallet with a high threshold for these roles to distribute control and reduce single points of failure. Additionally, establish clear operational procedures and monitoring for all privileged actions, particularly those related to minting and cap adjustments. For future iterations, evaluate the benefits of an upgradeable contract architecture to allow for greater flexibility in addressing potential issues or evolving protocol requirements without requiring a full token migration.

Contract

TypeCovalentXToken

Audit History

2 audits on record

Jul 2566Jul 2779Sep 474

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

Is Covalent X Token Safe?

Security Findings

Centralized Control of Minting Cap

High Power of DEFAULT_ADMIN_ROLE

Miner Manipulability of `block.timestamp` for Minting

Missing Zero Address Check for `emissionManager` in Constructor

Non-Upgradeable Contract

Permit2 Default Max Approval

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Covalent X Token?