Quantum Audit Logo
Launch App

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

Is Convex Token Safe?

CVXEthereum
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
SummaryAI Copilot

This audit was conducted on a partial codebase consisting of Solidity libraries and interfaces.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30%
  • Liquidity not locked
  • 1 Low finding(s) from audit
Exact 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

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
63.3%Contracts7.8%28.9%Everyone else
63.3%Contracts7.8%28.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
71.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking63.3%
  • Walletsanonymous holders, free to sell7.8%
  • Everyone elsethe rest of the supply28.9%
Effective concentrationwhat the score reads33.1%
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$9.14M across 10 pairs
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$6.48MShare of depth70.9%
Top-1 Unlocked Holder34.9%
Top-3 Unlocked74.2%
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.

Security Findings

1 Low3 Info
Low

Older Solidity Compiler Version Used

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

Issue

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

Fix

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

Status

Unresolved

Info

Incomplete Codebase Provided for Audit

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

Issue

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

Fix

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

Status

Unresolved

Info

Extensive External Contract Interactions (Inferred)

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

Issue

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

Fix

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

Status

Unresolved

Info

Centralized Control Points and Privileged Roles (Inferred)

Interfaces 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.I-03

Issue

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

Fix

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

Status

Unresolved

Analysis

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

This audit was conducted on a partial codebase consisting of Solidity libraries and interfaces. The core contract logic, such as the ConvexToken implementation or the main protocol contracts that utilize these interfaces, was not provided. Therefore, a comprehensive security assessment of the entire protocol was not possible. The analysis focuses on the provided components, which demonstrate good practices like SafeMath and ReentrancyGuard, but cannot evaluate the overall system's security posture.

Technical8/10Low risk

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.

Governance2/10High risk

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

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

A comprehensive security audit requires the complete and final source code of all deployed contracts.

Without the core contract logic, this assessment is severely limited. It is strongly recommended to provide the full codebase for a complete security review, including all implementation details, access control mechanisms, and external interaction patterns. Ensure all critical functions are protected by appropriate access control and that all external calls are handled securely, especially in a complex DeFi environment with numerous dependencies.

Contract & Record

1 audit on record
TypeConvexToken
NetworkEthereum
Token age4y
Contract0x4e3f…9d2b
Deployer0x947b…0277
Badge for your website
Convex Token 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. Sep 4, 202641Medium
  2. Aug 11, 202656Medium

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

Would You Like a More Detailed Audit of Convex Token?

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

Get Detailed Audit Is this your token? Publish your own audit on this page