Quantum Audit Logo

Is Radicle Safe?

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

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

Radicle RAD
0x31c8…64a3
Ethereum Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The audit of the RadicleToken contract identified a critical issue due to incomplete source code, preventing a full security assessment of core functionalities. Key helper functions and a significant portion of the transfer logic are missing. Additionally, the contract deviates from the ERC-20 standard by using `uint96` for internal balances and allowances, which could lead to integration challenges and potential value truncation. While the contract implements EIP-712 for delegation and permits, the foundational issues with code completeness and non-standard data types pose significant risks.

1 Critical1 High1 Medium1 Informational
Volume 24h
$3.2K
Liquidity
$1.95M
Price
$0.2366
Token Age
5y
Top 10 Holders
76.9%

Security Findings

Critical

Incomplete Code Provided for Audit

C-01The provided contract code is truncated, specifically the `_transferTokens` function, which is central to the token's core transfer logic. Additionally, the `safe96`, `sub96`, and `getChainId` helper functions, which are critical for arithmetic safety and EIP-712 domain separation, are not included. This prevents a comprehensive security assessment of critical arithmetic and core functionality, leaving significant portions of the contract unaudited.
IssueThe provided contract code is truncated, specifically the `_transferTokens` function, which is central to the token's core transfer logic. Additionally, the `safe96`, `sub96`, and `getChainId` helper functions, which are critical for arithmetic safety and EIP-712 domain separation, are not included. This prevents a comprehensive security assessment of critical arithmetic and core functionality, leaving significant portions of the contract unaudited.
FixProvide the complete and accurate source code for the RadicleToken contract, including the full `_transferTokens` function and all referenced helper functions (`safe96`, `sub96`, `getChainId`). Without the complete code, a thorough security assessment cannot be performed.
StatusUnresolved
High

Non-Standard `uint96` for ERC-20 Balances and Allowances

H-01The contract uses `uint96` for internal `balances` and `allowances` mappings, deviating from the ERC-20 standard's expectation of `uint256`. While external functions cast to `uint256`, this non-standard internal representation limits the maximum possible balance/allowance to `2^96 - 1` (approximately 7.9 x 10^28), which is significantly less than `2^256 - 1`. This could lead to unexpected behavior, truncation, or integration issues with systems expecting full `uint256` capacity, potentially causing loss of funds or operational failures if token values exceed `uint96` limits.
IssueThe contract uses `uint96` for internal `balances` and `allowances` mappings, deviating from the ERC-20 standard's expectation of `uint256`. While external functions cast to `uint256`, this non-standard internal representation limits the maximum possible balance/allowance to `2^96 - 1` (approximately 7.9 x 10^28), which is significantly less than `2^256 - 1`. This could lead to unexpected behavior, truncation, or integration issues with systems expecting full `uint256` capacity, potentially causing loss of funds or operational failures if token values exceed `uint96` limits.
FixConsider refactoring the contract to use `uint256` for `balances` and `allowances` to fully comply with the ERC-20 standard and avoid potential issues with value truncation or integration with other DeFi protocols. If `uint96` is intentionally used for gas optimization, ensure all external interfaces and integrations are fully aware of and compatible with this limitation.
StatusUnresolved
Medium

Direct `uint256` Subtraction for `totalSupply`

M-01In the `burnFrom` function, `totalSupply -= rawAmount;` performs a direct `uint256` subtraction without explicit `SafeMath` or Solidity 0.8+ checked arithmetic. While `rawAmount` is constrained by `safe96` to fit `uint96` and `balances[account]` is checked via `sub96`, relying on these indirect checks for `totalSupply`'s `uint256` arithmetic is less robust. An edge case where `totalSupply` is less than `rawAmount` (e.g., due to an external bug or unexpected state) could lead to an underflow if not implicitly handled by the `sub96` check on `balances[account]`.
IssueIn the `burnFrom` function, `totalSupply -= rawAmount;` performs a direct `uint256` subtraction without explicit `SafeMath` or Solidity 0.8+ checked arithmetic. While `rawAmount` is constrained by `safe96` to fit `uint96` and `balances[account]` is checked via `sub96`, relying on these indirect checks for `totalSupply`'s `uint256` arithmetic is less robust. An edge case where `totalSupply` is less than `rawAmount` (e.g., due to an external bug or unexpected state) could lead to an underflow if not implicitly handled by the `sub96` check on `balances[account]`.
FixImplement explicit `SafeMath` for `uint256` operations, or upgrade the Solidity compiler to version 0.8.0 or higher, which includes built-in overflow/underflow checks. This would provide a more robust and explicit guarantee against `totalSupply` underflow.
StatusUnresolved
Info

Use of Older Solidity Compiler Version

I-01The contract is compiled with `pragma solidity ^0.7.5;`. While not a direct vulnerability, using an older compiler version means the contract does not benefit from security enhancements, bug fixes, and optimizations introduced in newer versions (e.g., implicit overflow/underflow checks in Solidity 0.8.0+).
IssueThe contract is compiled with `pragma solidity ^0.7.5;`. While not a direct vulnerability, using an older compiler version means the contract does not benefit from security enhancements, bug fixes, and optimizations introduced in newer versions (e.g., implicit overflow/underflow checks in Solidity 0.8.0+).
FixConsider upgrading the Solidity compiler version to 0.8.0 or higher. This would allow the contract to leverage newer language features, security improvements, and optimizations, such as built-in overflow/underflow checks, reducing the need for custom `SafeMath` implementations.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract implements a standard ERC-20 token with additional governance features, including EIP-712 based delegation and permit functionality (7.2 Code Security). Nonces are correctly managed to prevent replay attacks in `delegateBySig` and `permit`. However, a critical concern is the truncated `_transferTokens` function and missing `safe96`, `sub96`, and `getChainId` helper functions, which prevents a complete audit of core logic and arithmetic safety (7.1 Architecture, 7.2 Code Security). The use of `uint96` for internal balances and allowances deviates from the ERC-20 standard, potentially causing integration issues or value truncation (7.1 Architecture, 7.6 External).

GovernanceHigh1/10

The contract includes a Compound-style delegation mechanism, allowing token holders to delegate their voting power, which is a positive for decentralized governance (7.5 Governance). The `burnFrom` function allows for token burning, reducing total supply. However, the `uint96` limitation on balances and allowances could restrict the economic scale of the token, potentially impacting large-scale operations or future growth (7.4 Economic). The direct `uint256` subtraction for `totalSupply` in `burnFrom`, while implicitly protected by other checks, is less robust than explicit safe math for `uint256` (7.4 Economic).

UpgradesMedium6/10

The RadicleToken contract is a standard implementation and does not incorporate any proxy patterns or upgradeability mechanisms (7.7 Upgrades). Therefore, it is not subject to upgrade-related risks.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

18.8% in wallets58.1% in contracts
Effective Concentration42.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

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

Key Addresses

Deployer
0x6838…dc35
Unlocked LP Held By
0x8da8…30ba0x2ee8…d4020x97b1…b9820xb3ac…68a00x3d50…dd3a0x826f…1e650x0000…8a900x1f2f…f387

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (76.9% total → 42.1% effective; 18.8% in EOAs, 58.1% in contracts — moderate)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • LP claimed locked but only 0.0% actually locked
  • 1 Critical finding(s) from audit
  • 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

DeXeHigh RiskMantle (MNT)High RiskOcean Token (OCEAN)High RiskToken Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskHarryPotterObamaSonic10Inu (BITCOIN)High Risk

Would You Like a More Detailed Audit of Radicle?

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

Get Detailed Audit