On-chain security analysis — is it a scam or legit?
EthereumThe 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.
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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xcf37…659a0x9b81…7db90x9e8b…fda0No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
mint function allows unauthorized token creationDelegationToken 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.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.
Ensure 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.
Unresolved
ERC20 implementationDelegationToken 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).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).
Conduct 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.
Unresolved
rely access control mechanismCFG 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).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).
Ensure 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.
Unresolved
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.
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).
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).
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.
Immediately address the critical access control vulnerability related to the public mint function in DelegationToken.
Ensure that token creation is strictly controlled by an authorized entity or a robust governance mechanism. Additionally, conduct a comprehensive audit of the underlying protocol-v3/misc/ERC20.sol contract to verify its security and adherence to ERC-20 standards, especially regarding sensitive functions like mint and burn. Document the full access control architecture, including the role and permissions of the ward address.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Centrifuge (CFG) contract on Ethereum is 0xcccccccccc33d538dbc2ee4feab0a7a1ff4e8a94. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Centrifuge is 58/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.12M.
As of Sep 4, 2026, the 10 largest holders own 46.8% of the supply. The Holders section on this page shows who they are by holder type.
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
