Quantum Audit Logo
Launch App

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

Is Radicle Safe?

RADEthereum
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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance1/10Upgrades6/10Checks passed4 of 5Findings1 Critical · 1 High · 1 Medium · 1 Info4
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.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 30%
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 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
Exact factors
  • 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
58.1%Contracts18.8%Wallets23.1%Everyone else
58.1%Contracts18.8%Wallets23.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
76.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking58.1%
  • Walletsanonymous holders, free to sell18.8%
  • Everyone elsethe rest of the supply23.1%
Effective concentrationwhat the score reads42.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$1.95M across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$1.95MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical1 High1 Medium1 Info
Critical

Incomplete Code Provided for Audit

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

Issue

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

Fix

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

Status

Unresolved

High

Non-Standard uint96 for ERC-20 Balances and Allowances

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

Issue

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

Fix

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

Status

Unresolved

Medium

Direct uint256 Subtraction for totalSupply

In 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].M-01

Issue

In 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].

Fix

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

Status

Unresolved

Info

Use of Older Solidity Compiler Version

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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

Governance1/10High risk

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

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is critical to provide the complete and accurate source code, including all helper functions (safe96, sub96, getChainId) and the full _transferTokens implementation, to enable a comprehensive security audit.

The project should carefully evaluate the implications of using uint96 for internal balances and allowances, considering potential compatibility issues and limitations for future growth, and consider migrating to uint256 for full ERC-20 compliance. Additionally, consider upgrading the Solidity compiler to version 0.8.0 or higher to benefit from built-in overflow/underflow checks and other security enhancements.

Contract & Record

1 audit on record
TypeRadicleToken
NetworkEthereum
Token age5y
Contract0x31c8…64a3
Deployer0x6838…dc35
Badge for your website
Radicle 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. Aug 11, 202660Medium

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

Frequently Asked Questions

What is the RAD contract address?

The Radicle (RAD) contract on Ethereum is 0x31c8eacbffdd875c74b94b077895bd78cf1e64a3. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Radicle a scam?

Quantum Audit's risk score for Radicle is 60/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is RAD liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $1.95M.

Who holds RAD?

As of Sep 4, 2026, the 10 largest holders own 76.9% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
DeXeEthereum60MediumMantleMNT · Ethereum60MediumOcean TokenOCEAN · Ethereum60MediumShuffleSHFL · Ethereum60MediumTajirTJR · Ethereum60MediumToken Prometeus NetworkPROM · Ethereum59Medium

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 Is this your token? Publish your own audit on this page