Is Convex Token (CVX) Safe? Smart Contract Security Analysis

Security Findings

1 Low3 Info

Low

Older Solidity Compiler Version Used

L-01The contract uses `pragma solidity 0.6.12`. While this version is functional, newer Solidity versions (e.g., 0.8.x) offer significant improvements in terms of security features (e.g., default overflow/underflow checks for `uint` types), gas optimizations, and clearer error handling. Relying on older versions might miss out on these enhancements.

IssueThe contract uses `pragma solidity 0.6.12`. While this version is functional, newer Solidity versions (e.g., 0.8.x) offer significant improvements in terms of security features (e.g., default overflow/underflow checks for `uint` types), gas optimizations, and clearer error handling. Relying on older versions might miss out on these enhancements.

FixConsider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x). This would allow leveraging modern compiler features that enhance security and potentially reduce gas costs. Thorough testing would be required after any compiler upgrade.

StatusUnresolved

Info

Incomplete Codebase Provided for Audit

I-01The provided source code consists only of helper libraries and interfaces. The main contract logic (e.g., the implementation of `ConvexToken` or the primary protocol contracts) was not included. This limitation prevents a comprehensive security audit of the entire protocol, making it impossible to assess critical aspects such as business logic, state transitions, access control implementations, and overall system architecture.

IssueThe provided source code consists only of helper libraries and interfaces. The main contract logic (e.g., the implementation of `ConvexToken` or the primary protocol contracts) was not included. This limitation prevents a comprehensive security audit of the entire protocol, making it impossible to assess critical aspects such as business logic, state transitions, access control implementations, and overall system architecture.

FixProvide the complete and final source code for all contracts intended for deployment or currently in production. This includes all implementation contracts, proxy contracts, and any other relevant components to enable a full and accurate security assessment.

StatusUnresolved

Info

Extensive External Contract Interactions (Inferred)

I-02The numerous interfaces (e.g., `ICurveGauge`, `IStaker`, `IRewards`, `IMinter`, `IVoting`) indicate that the protocol interacts extensively with a wide array of external contracts. While `ReentrancyGuard` is present, extensive external calls inherently increase the attack surface for issues like unexpected return values, reentrancy (if not consistently applied), and reliance on the security of third-party contracts. Without the main contract logic, the specific patterns and safeguards for these interactions cannot be fully evaluated.

IssueThe numerous interfaces (e.g., `ICurveGauge`, `IStaker`, `IRewards`, `IMinter`, `IVoting`) indicate that the protocol interacts extensively with a wide array of external contracts. While `ReentrancyGuard` is present, extensive external calls inherently increase the attack surface for issues like unexpected return values, reentrancy (if not consistently applied), and reliance on the security of third-party contracts. Without the main contract logic, the specific patterns and safeguards for these interactions cannot be fully evaluated.

FixEnsure that all external calls are handled with robust checks for return values, gas limits, and potential reentrancy. Implement circuit breakers or emergency stop mechanisms for critical external dependencies. Thoroughly audit all integrated third-party contracts and understand their security implications.

StatusUnresolved

Info

Centralized Control Points and Privileged Roles (Inferred)

I-03Interfaces such as `IRewardFactory` with `setAccess`, `IPools` with `setPoolManager`, and `IStaker` with `operator` suggest the presence of privileged roles or centralized control points within the protocol. These roles typically have significant power, such as adding/removing pools, setting access permissions, or executing arbitrary calls. The security of the protocol heavily depends on the secure implementation and management of these roles.

IssueInterfaces such as `IRewardFactory` with `setAccess`, `IPools` with `setPoolManager`, and `IStaker` with `operator` suggest the presence of privileged roles or centralized control points within the protocol. These roles typically have significant power, such as adding/removing pools, setting access permissions, or executing arbitrary calls. The security of the protocol heavily depends on the secure implementation and management of these roles.

FixClearly define and document all privileged roles and their associated permissions. Implement robust access control mechanisms (e.g., OpenZeppelin's Ownable or AccessControl) and consider multi-signature wallets for critical operations. Ensure that role management is secure and transparent, and that emergency procedures are in place for compromised keys.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The provided code includes robust libraries such as `SafeMath` for arithmetic safety and `ReentrancyGuard` to prevent reentrancy attacks, which are positive indicators for code security (7.2 Code Security). The `Address` library also includes standard utility functions. However, the absence of the main contract logic (7.1 Architecture) severely limits the ability to assess specific implementation vulnerabilities, external interaction risks (7.6 External), or the overall technical architecture. The use of Solidity 0.6.12 is an older version, which might lack some modern compiler optimizations and safety features.

GovernanceHigh2/10

The interfaces suggest a complex DeFi protocol involving staking, voting, rewards, and fee distribution (7.4 Economic, 7.5 Governance). Interfaces like `IVoting`, `IStaker`, `IRewards`, and `IFeeDistro` indicate a sophisticated economic model and governance structure. The presence of functions like `vote_for_gauge_weights` and `setPoolManager` implies significant control mechanisms. Without the core contract logic, it is impossible to evaluate the security of these economic incentives, potential manipulation vectors, or the robustness of the governance mechanisms and access control (7.3 Access Control).

UpgradesMedium4/10

The provided code snippet does not contain any explicit upgrade mechanisms or proxy patterns (7.7 Upgrades). Therefore, no assessment of upgrade safety can be made based on this limited information. If the full protocol utilizes an upgradeable architecture, a thorough review of its proxy implementation, initialization, and upgradeability patterns would be critical to ensure safety and prevent potential vulnerabilities during contract updates.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

71.1% in top 10

7.8% in wallets63.3% in contracts

Effective Concentration33.1%

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

$9.14M across 10 pairs

CurveWETHanalysed$6.48M CurvefrxETH$1.83M SushiswapWETH$310.4K Uniswap v3CRV$196.6K Uniswap v4USDC$166.4K Uniswap v3WETH$119.4K

Show 4 more pairsShow less

Uniswap v4ETH$42.6K PancakeswapWETH$48 Uniswap v2WETH$6 SushiswapCRV$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 Holder34.9%

Top-3 Unlocked74.2%

Key Addresses

11 addresses

Deployer

0x947b…0277

Unlocked LP Held By

0x3887…7f1c0x2291…2b3c0x5f46…06050x947b…02770x33ed…0acc0x9d61…e1060xdcfa…f24f0x54f3…78870xd01a…e3380x75c2…b958

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

5 factors

Ownership NOT renounced (admin/mint authority retained)
Mintable supply, but capped at 0.0%/year
Top-10 concentration > 30% (71.1% total → 33.1% effective; 7.8% in EOAs, 63.3% in contracts — moderate)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
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

Is Convex Token Safe?

Security Findings

Older Solidity Compiler Version Used

Incomplete Codebase Provided for Audit

Extensive External Contract Interactions (Inferred)

Centralized Control Points and Privileged Roles (Inferred)

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Convex Token?