Quantum Audit Logo

Is Centrifuge Safe?

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

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

Centrifuge CFG
0xcccc…8a94
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the Centrifuge CFG token contracts (CFG and DelegationToken) identified a critical access control vulnerability related to the public `mint` function, which could allow unauthorized token creation. Other aspects, such as delegation logic and arithmetic operations, appear robust. The contracts are not upgradeable. A full review of the base ERC20 contract is recommended.

1 Critical1 Low1 Informational
Volume 24h
$118.5K
Liquidity
$1.04M
Price
$0.1079
Token Age
1y
Top 10 Holders
46.8%

Security Findings

1 Crit1 Low1 Info
Critical

Public `mint` function allows unauthorized token creation

C-01The `DelegationToken` contract declares `function mint(address to, uint256 value) public override(ERC20)`. If the overridden `ERC20.mint` function (or the underlying `_mint` function it calls) does not implement proper access control (e.g., `onlyOwner`, `onlyMinter`), then any external caller can invoke this `mint` function to create an arbitrary amount of tokens. This would lead to an infinite supply and complete devaluation of the token. The provided code snippet for `DelegationToken` does not add any access control to this `public` function.
IssueThe `DelegationToken` contract declares `function mint(address to, uint256 value) public override(ERC20)`. If the overridden `ERC20.mint` function (or the underlying `_mint` function it calls) does not implement proper access control (e.g., `onlyOwner`, `onlyMinter`), then any external caller can invoke this `mint` function to create an arbitrary amount of tokens. This would lead to an infinite supply and complete devaluation of the token. The provided code snippet for `DelegationToken` does not add any access control to this `public` function.
FixEnsure that the `mint` function in `DelegationToken` (or its base `ERC20` implementation) is adequately protected by an access control mechanism, such as `onlyOwner` or `onlyMinter`, to prevent unauthorized token creation. If the intention is for `mint` to be callable by specific roles, those roles must be enforced.
StatusUnresolved
Low

Dependency on unprovided `ERC20` implementation

L-01The `DelegationToken` contract inherits from `ERC20` located at `protocol-v3/misc/ERC20.sol`. The full source code for this base `ERC20` contract was not provided for review. The security and correctness of `DelegationToken` heavily depend on the robustness and proper implementation of this external `ERC20` contract, especially concerning access control for functions like `mint` and `burn`, and standard ERC-20 behaviors (7.6 External).
IssueThe `DelegationToken` contract inherits from `ERC20` located at `protocol-v3/misc/ERC20.sol`. The full source code for this base `ERC20` contract was not provided for review. The security and correctness of `DelegationToken` heavily depend on the robustness and proper implementation of this external `ERC20` contract, especially concerning access control for functions like `mint` and `burn`, and standard ERC-20 behaviors (7.6 External).
FixConduct a thorough audit of the `protocol-v3/misc/ERC20.sol` contract to ensure it adheres to security best practices and correctly implements ERC-20 standards, particularly regarding access control for sensitive functions like `mint` and `burn`.
StatusUnresolved
Info

Unspecified `rely` access control mechanism

I-01The `CFG` contract constructor calls `rely(ward)`. This suggests the use of a `DSAuth`-like access control pattern where a `ward` address is granted permissions. However, the `rely` function and any corresponding `auth` checks are not present in the provided code. Without the full implementation of this access control system, the scope of the `ward`'s privileges and the overall access control model cannot be fully assessed (7.3 Access Control).
IssueThe `CFG` contract constructor calls `rely(ward)`. This suggests the use of a `DSAuth`-like access control pattern where a `ward` address is granted permissions. However, the `rely` function and any corresponding `auth` checks are not present in the provided code. Without the full implementation of this access control system, the scope of the `ward`'s privileges and the overall access control model cannot be fully assessed (7.3 Access Control).
FixEnsure that the `rely` and `auth` mechanisms are correctly implemented and that the `ward` address's permissions are clearly defined and limited to necessary administrative functions. Document the full access control architecture.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture is based on a standard ERC-20 token with added delegation capabilities, leveraging Solidity 0.8.28 for enhanced safety. The `delegateWithSig` function correctly uses nonces to prevent replay attacks (7.2 Code Security). However, a critical access control vulnerability exists where the `mint` function in `DelegationToken` is declared `public`, potentially allowing unauthorized token creation if the base `ERC20` contract lacks proper restrictions (7.3 Access Control). The `burn` function in `CFG` uses an `unchecked` block safely due to prior checks, and `_moveDelegateVotes` handles voting power updates without arithmetic overflows/underflows (7.2 Code Security).

GovernanceHigh2/10

The token implements a standard delegation mechanism for governance, allowing holders to delegate voting power. This design is common for decentralized governance systems (7.5 Governance). The economic model relies on the integrity of the token supply. The critical vulnerability regarding the public `mint` function poses an extreme economic risk, as it could lead to infinite token supply and complete value destruction (7.4 Economic). The `CFG` constructor's `rely(ward)` call suggests a privileged administrative address, which introduces a dependency on the security of this `ward` (7.3 Access Control).

UpgradesHigh2/10

The provided contracts do not implement any explicit upgradeability patterns (e.g., proxy contracts). This means the contracts are immutable once deployed (7.7 Upgrades). Any future changes or bug fixes would require a new deployment and a migration of assets, which can be a complex and risky process. This immutability ensures no future changes can introduce new vulnerabilities, but also means no fixes are possible post-deployment without a full redeployment.

Security Checklist

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

Holder Composition

46.8% in top 10
42.0% in wallets4.8% in contracts
Effective Concentration43.9%

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

$1.12M across 9 pairs
Uniswap v4ETHanalysed$1.04M93.6%Uniswap v4USDT$39.2K3.5%Uniswap v4USDT$25.1K2.3%Uniswap v4ETH$4.0K0.4%Uniswap v3WETH$1.5K0.1%Uniswap v4ETH$1.4K0.1%

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

Key Addresses

4 addresses
Deployer
0x7270…ada4
Unlocked LP Held By
0xcf37…659a0x9b81…7db90x9e8b…fda0

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

What Raised This Score

7 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (46.8% total → 43.9% effective; 42.0% in EOAs, 4.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • 1 Critical 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
Tether Gold (XAUT)High RiskMatrix (MTX)High RiskAnimecoin (ANIME)High RiskToken Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskPrismHigh Risk

Would You Like a More Detailed Audit of Centrifuge?

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

Get Detailed Audit