Quantum Audit Logo

Is Relics Safe?

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

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

Relics RELICS
0x8f29…2da9
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The RelicsToken contract implements an ERC20 token with custom logic for tracking 'active holders' and interacting with an NFT system. The audit identified a critical operational flaw related to the contract's configurability given its renounced ownership status, alongside a high-severity reentrancy risk. Several informational points regarding economic design and external dependencies were also noted. The prefill indicates ownership is renounced, which significantly impacts the contract's operational flexibility.

1 Critical1 High1 Medium1 Informational
Volume 24h
$2.6K
Liquidity
$30.1K
Price
$9.2900
Token Age
7d
Top 10 Holders
42.9%

Security Findings

1 Crit1 High1 Med1 Info
Critical

Critical Unconfigurable Parameters Due to Renounced Ownership

C-01The `relicsNFT`, `relicSyncPool`, and `relicLocker` addresses are critical for the contract's functionality, enabling interactions with the NFT system and defining special accounts. These addresses are set via `onlyOwner` functions (`setRelicsNFT`, `setRelicSyncPool`, `setRelicLocker`). The prefill data indicates that ownership of the contract is renounced. If these parameters are not configured during the initial deployment transaction or immediately thereafter (before ownership renunciation), they can never be set, rendering core functionalities like `transferRelicToken`, `_update`'s `syncBalances` call, and `_syncHolder` exclusions permanently non-functional or severely limited. This rep…
IssueThe `relicsNFT`, `relicSyncPool`, and `relicLocker` addresses are critical for the contract's functionality, enabling interactions with the NFT system and defining special accounts. These addresses are set via `onlyOwner` functions (`setRelicsNFT`, `setRelicSyncPool`, `setRelicLocker`). The prefill data indicates that ownership of the contract is renounced. If these parameters are not configured during the initial deployment transaction or immediately thereafter (before ownership renunciation), they can never be set, rendering core functionalities like `transferRelicToken`, `_update`'s `syncBalances` call, and `_syncHolder` exclusions permanently non-functional or severely limited. This rep…
FixEnsure that all critical configuration parameters (`relicsNFT`, `relicSyncPool`, `relicLocker`) are set either within the constructor or through `onlyOwner` functions immediately after deployment, and *before* ownership is renounced. A multi-signature wallet or a time-locked governance mechanism could be used to manage these settings if ownership is not renounced, but given the renounced status, initial setup is paramount. Consider a deployment script that atomically sets these values.
StatusUnresolved
High

Reentrancy Risk in `_update` via External Call to `IRelicsNFT.syncBalances`

H-01The `_update` function, which is called during every ERC20 transfer (e.g., `transfer`, `transferFrom`), makes an external call to `IRelicsNFT(nft).syncBalances(from, to)`. While the `_relicTransferInProgress` flag is used to prevent reentrancy specifically during `transferRelicToken` calls, it does not protect against re-entrant calls initiated by standard ERC20 transfers. If the `relicsNFT` contract is malicious or compromised, it could re-enter `RelicsToken` (e.g., by calling `transfer` again) before the `_update` function completes, leading to unexpected state changes or token manipulation (7.2 Code Security).
IssueThe `_update` function, which is called during every ERC20 transfer (e.g., `transfer`, `transferFrom`), makes an external call to `IRelicsNFT(nft).syncBalances(from, to)`. While the `_relicTransferInProgress` flag is used to prevent reentrancy specifically during `transferRelicToken` calls, it does not protect against re-entrant calls initiated by standard ERC20 transfers. If the `relicsNFT` contract is malicious or compromised, it could re-enter `RelicsToken` (e.g., by calling `transfer` again) before the `_update` function completes, leading to unexpected state changes or token manipulation (7.2 Code Security).
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard` or a simple mutex) around the `_update` function, or specifically around the external call to `IRelicsNFT(nft).syncBalances`. This would prevent re-entrant calls from external contracts during any token transfer operation.
StatusUnresolved
Medium

Low Fixed Supply and Potential for Price Volatility

M-01The `RelicsToken` has a `FIXED_SUPPLY` of 10,000 tokens (10,000 ether). This is a relatively small total supply for an ERC20 token. While not a direct code vulnerability, a low supply can contribute to higher price volatility and potentially make the token more susceptible to market manipulation, especially if liquidity is also low. The economic impact depends heavily on the token's intended utility and role within the broader Relics ecosystem (7.4 Economic).
IssueThe `RelicsToken` has a `FIXED_SUPPLY` of 10,000 tokens (10,000 ether). This is a relatively small total supply for an ERC20 token. While not a direct code vulnerability, a low supply can contribute to higher price volatility and potentially make the token more susceptible to market manipulation, especially if liquidity is also low. The economic impact depends heavily on the token's intended utility and role within the broader Relics ecosystem (7.4 Economic).
FixWhile changing the fixed supply is not possible post-deployment, it is important to acknowledge and manage the implications of a low supply. Implement robust liquidity provisions and consider mechanisms to mitigate extreme price fluctuations if the token is intended for broad market use. Clearly communicate the economic model and potential volatility to users.
StatusUnresolved
Info

Dependency on External `IRelicsNFT` Contract

I-01The `RelicsToken` contract has a significant dependency on the `IRelicsNFT` interface and its implementation. Functions like `_update` call `IRelicsNFT(nft).syncBalances(from, to)`, and `_requireHoldsNoRelics` calls `IRelicsNFT(nft).balanceOf(account)`. The security and correct functioning of `RelicsToken` are directly tied to the security, behavior, and availability of the `IRelicsNFT` contract. Any vulnerabilities, unexpected behavior, or upgrade issues in `IRelicsNFT` could directly impact `RelicsToken` (7.6 External).
IssueThe `RelicsToken` contract has a significant dependency on the `IRelicsNFT` interface and its implementation. Functions like `_update` call `IRelicsNFT(nft).syncBalances(from, to)`, and `_requireHoldsNoRelics` calls `IRelicsNFT(nft).balanceOf(account)`. The security and correct functioning of `RelicsToken` are directly tied to the security, behavior, and availability of the `IRelicsNFT` contract. Any vulnerabilities, unexpected behavior, or upgrade issues in `IRelicsNFT` could directly impact `RelicsToken` (7.6 External).
FixEnsure that the `IRelicsNFT` contract is thoroughly audited, well-maintained, and deployed at a trusted address. Implement robust monitoring for the `IRelicsNFT` contract to detect any anomalies or compromises that could affect `RelicsToken`.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates good adherence to ERC20 standards and uses OpenZeppelin's Ownable for access control (7.3). Custom error messages enhance clarity, and `unchecked` blocks for counters are used appropriately (7.2 Code Security). However, a significant reentrancy risk exists in the `_update` function due to an external call to `IRelicsNFT.syncBalances` without a reentrancy guard for standard ERC20 transfers (7.2 Code Security). The architecture (7.1) relies on external contracts, introducing dependency risks (7.6 External).

GovernanceMedium4/10

The economic design includes a fixed, relatively low supply of 10,000 tokens (7.4 Economic), which could lead to high volatility. The `HOLDER_THRESHOLD` mechanism for 'active holders' is a core economic feature, but its full impact depends on the broader ecosystem. The most significant governance and operational risk (7.8 Operations) stems from the renounced ownership combined with critical unconfigurable parameters, which could render key functionalities unusable if not set during deployment.

UpgradesLow8/10

The RelicsToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard implementation contract, meaning its logic cannot be modified after deployment. This eliminates upgrade-specific risks but also means any discovered issues require a new deployment and migration.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

42.9% in top 10
12.0% in wallets30.9% in contracts
Effective Concentration24.3%

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

$30.1K

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

2 addresses
Deployer
0x0bda…9893
Unlocked LP Held By
0x147a…03f8

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

What Raised This Score

9 factors
  • Top-10 concentration > 20% (42.9% total → 24.3% effective; 12.0% in EOAs, 30.9% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($30,116 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 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

6 more on the record
Uniswap (UNI)High RiskBIOHigh RiskVirtuals Protocol (VIRTUAL)High RiskDerive (DRV)High RiskLido DAO (LDO)High RiskFOXHigh Risk

Would You Like a More Detailed Audit of Relics?

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

Get Detailed Audit