Quantum Audit Logo

Is Curve DAO Safe?

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

Is this your token? Publish your own audit on this page →

Curve DAO CRV
0xd533…cd52
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers the Curve DAO Token (CRV) contract, an ERC-20 token with a custom piecewise-linear mining supply mechanism implemented in Vyper. The contract manages token transfers, approvals, and a defined inflation schedule. Due to the provided source code being truncated, a full verification of the `transferFrom` function was not possible, which introduces a significant limitation to the technical assessment.

1 High1 Medium3 Informational
Volume 24h
$502.3K
Liquidity
$1.90M
Price
$0.3685
Token Age
3y
Top 10 Holders
56.6%

Security Findings

1 High1 Med3 Info
High

Truncated Source Code for `transferFrom` Function

H-01The provided source code for the `transferFrom` function is incomplete (`self.ba...`). This prevents a full and accurate security assessment of this critical ERC-20 functionality, which is essential for token transfers initiated by approved third parties. Without the complete code, potential vulnerabilities such as incorrect allowance checks, reentrancy, or arithmetic errors cannot be ruled out.
IssueThe provided source code for the `transferFrom` function is incomplete (`self.ba...`). This prevents a full and accurate security assessment of this critical ERC-20 functionality, which is essential for token transfers initiated by approved third parties. Without the complete code, potential vulnerabilities such as incorrect allowance checks, reentrancy, or arithmetic errors cannot be ruled out.
FixProvide the complete and verified source code for all functions within the contract to enable a thorough security audit. Ensure that the `transferFrom` implementation correctly handles allowances, balances, and prevents reentrancy or integer issues.
StatusUnresolved
Medium

Centralized Control by Admin and Minter Roles

M-01The `admin` role has significant power, including the ability to set the `minter` address (once) and transfer the `admin` role itself via `set_admin`. The `minter` role, once set, controls the actual issuance of new tokens based on the contract's inflation schedule. This centralization of control introduces a single point of failure and potential for malicious or compromised actors to manipulate token supply or administrative privileges (7.3 Access Control).
IssueThe `admin` role has significant power, including the ability to set the `minter` address (once) and transfer the `admin` role itself via `set_admin`. The `minter` role, once set, controls the actual issuance of new tokens based on the contract's inflation schedule. This centralization of control introduces a single point of failure and potential for malicious or compromised actors to manipulate token supply or administrative privileges (7.3 Access Control).
FixConsider implementing multi-signature wallets for the `admin` and `minter` roles to distribute control and require multiple approvals for critical operations. Alternatively, implement time-locks for sensitive administrative actions to provide a window for community review and intervention.
StatusUnresolved
Info

Precision Loss in Rate Calculation Due to Integer Division

I-01The `_update_mining_parameters` and `mintable_in_timeframe` functions perform rate calculations using integer division (`_rate = _rate * RATE_DENOMINATOR / RATE_REDUCTION_COEFFICIENT`). While Vyper's integer division truncates, the contract's comment `double-division with rounding made rate a bit less => good` indicates this is an intentional design choice to bias the rate downwards, which is generally safer than upwards. However, it's important to acknowledge that this introduces minor precision loss over many epochs (7.4 Economic).
IssueThe `_update_mining_parameters` and `mintable_in_timeframe` functions perform rate calculations using integer division (`_rate = _rate * RATE_DENOMINATOR / RATE_REDUCTION_COEFFICIENT`). While Vyper's integer division truncates, the contract's comment `double-division with rounding made rate a bit less => good` indicates this is an intentional design choice to bias the rate downwards, which is generally safer than upwards. However, it's important to acknowledge that this introduces minor precision loss over many epochs (7.4 Economic).
FixNo direct action is required as this appears to be an intentional design choice. Document this behavior clearly in external specifications and ensure its implications are understood by stakeholders. If higher precision is ever required, consider using fixed-point arithmetic libraries or alternative calculation methods.
StatusUnresolved
Info

Hardcoded Loop Limit in `mintable_in_timeframe`

I-02The `mintable_in_timeframe` function uses a hardcoded loop limit of `for i in range(999)` to calculate future mintable supply. Given that `RATE_REDUCTION_TIME` is one year, this limits the calculation to approximately 999 years. While this is practically sufficient for the expected lifespan of the protocol, it is a fixed constraint that could theoretically be reached under extreme, long-term scenarios (7.1 Architecture).
IssueThe `mintable_in_timeframe` function uses a hardcoded loop limit of `for i in range(999)` to calculate future mintable supply. Given that `RATE_REDUCTION_TIME` is one year, this limits the calculation to approximately 999 years. While this is practically sufficient for the expected lifespan of the protocol, it is a fixed constraint that could theoretically be reached under extreme, long-term scenarios (7.1 Architecture).
FixNo immediate action is required given the practical implications. For future designs, if an indefinite or extremely long-term calculation is needed, consider an iterative approach that can be called multiple times or a more gas-efficient mathematical series calculation if possible.
StatusUnresolved
Info

Slight Supply Increase from Late `update_mining_parameters` Calls

I-03The `update_mining_parameters` function can be called by anyone, but if it's called late in an epoch (i.e., after the epoch boundary but before the next call), the `_available_supply` calculation will result in a slightly higher `start_epoch_supply` for the subsequent epoch. The contract comment `Total supply becomes slightly larger if this function is called late` acknowledges this design trade-off, which prioritizes decentralization of calls over perfect precision at epoch boundaries (7.4 Economic).
IssueThe `update_mining_parameters` function can be called by anyone, but if it's called late in an epoch (i.e., after the epoch boundary but before the next call), the `_available_supply` calculation will result in a slightly higher `start_epoch_supply` for the subsequent epoch. The contract comment `Total supply becomes slightly larger if this function is called late` acknowledges this design trade-off, which prioritizes decentralization of calls over perfect precision at epoch boundaries (7.4 Economic).
FixNo direct action is required as this is a known and accepted design trade-off. Ensure this behavior is clearly communicated to users and stakeholders. The impact is likely negligible given the scale of the token supply and the frequency of calls.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates strong technical foundations, leveraging Vyper's safety features for secure arithmetic operations and preventing common Solidity pitfalls (7.2 Code Security). Core ERC-20 functions like `transfer` are implemented correctly, including checks for zero address transfers. A significant limitation is the truncated `transferFrom` function in the provided source, which prevents a full audit of this critical token transfer mechanism (7.2 Code Security). The inflation logic, while complex, is clearly defined and uses constants for parameters, reducing runtime errors (7.1 Architecture).

GovernanceHigh1/10

The contract's economic model is based on a transparent, piecewise-linear inflation schedule, designed to distribute tokens over time (7.4 Economic). The `admin` role has centralized control over setting the `minter` and transferring administrative privileges, which introduces a single point of control for critical token management functions (7.3 Access Control). While the `minter` can only be set once, its power over token supply is substantial. The mechanism for updating mining parameters is decentralized, allowing any user to trigger epoch updates, which slightly increases total supply if called late, a known design trade-off (7.4 Economic).

UpgradesHigh3/10

The contract is not designed with upgradeability in mind, as it is a standard implementation without a proxy pattern (7.7 Upgrades). This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or malicious upgrade paths. Any changes to the core logic would require a new deployment and migration of assets, which is a significant undertaking.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

56.6% in top 10
21.4% in wallets35.2% in contracts
Effective Concentration35.5%

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

$6.46M across 24 pairs
Curve tricrvUSDanalysed$1.90M29.4%Curve triWETH$1.90M29.4%Uniswap v41INCH$734.0K11.4%Uniswap v3WETH$486.8K7.5%Uniswap v4ETH$434.2K6.7%Uniswap v3USDC$417.9K6.5%
Show 4 more pairsShow less
Uniswap v4UNI$175.1K2.7%Sushiswap v3WETH$159.9K2.5%Uniswap v2WETH$116.5K1.8%Uniswap v3WETH$81.1K1.3%

The 14 remaining pairs hold $55.8K between them and are not listed.

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 Holder65.7%
Top-3 Unlocked99.2%

Key Addresses

11 addresses
Deployer
0xc4ad…7be4
Unlocked LP Held By
0x6df1…ac720xf4df…ffe20xc20e…c12b0xaabc…d1120x359e…16b20x9b61…28080xb1eb…1a600xe584…39c70xac42…9ffc0xc5bb…45cd

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (56.6% total → 35.5% effective; 21.4% in EOAs, 35.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 65.7% (independent LP — depth risk, pool = 29% of DEX liquidity)
  • LP top3 unlocked holders = 99.2% (independent LP — depth risk, pool = 29% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
c8ntinuum (CTM)High RiskFrax USD (FRXUSD)High RiskEthena (ENA)High RiskEigenCloud (prev. EigenLayer) (EIGEN)High RiskCapHigh RiskYield Basis (YB)High Risk

Would You Like a More Detailed Audit of Curve DAO?

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

Get Detailed Audit