Quantum Audit Logo

Is SuperRare Safe?

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

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

SuperRare RARE
0xba5b…6350
Ethereum
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The SuperRareToken contract, implemented as an upgradeable ERC-20 token, utilizes OpenZeppelin's `ERC20PresetMinterPauserUpgradeable` and includes EIP-2612 permit functionality. The contract's architecture is generally sound, leveraging established upgradeability patterns. Key strengths include the use of a TransparentUpgradeableProxy with a multisig admin for upgrades, and a correctly implemented EIP-2612 permit function. Identified issues primarily relate to redundant code, use of an older Solidity version, and the inherent centralization of control associated with minter/pauser roles, which is common for such token designs.

1 Medium1 Low2 Informational
Volume 24h
$191.7K
Liquidity
$117.5K
Price
$0.01976
Token Age
1y
Top 10 Holders
56.3%

Security Findings

1 Med1 Low2 Info
Medium

Centralized Control over Token Supply and Operations

M-01The `SuperRareToken` contract, by inheriting `ERC20PresetMinterPauserUpgradeable`, grants significant control to specific roles. Accounts with the `MINTER_ROLE` can mint new tokens, potentially increasing the total supply beyond the initial amount. Accounts with the `PAUSER_ROLE` can pause all token transfers, effectively freezing the token. The `DEFAULT_ADMIN_ROLE` has the power to grant and revoke these roles. While the proxy's admin is a multisig, the direct control over token mechanics remains centralized within these roles, posing a risk if compromised or misused.
IssueThe `SuperRareToken` contract, by inheriting `ERC20PresetMinterPauserUpgradeable`, grants significant control to specific roles. Accounts with the `MINTER_ROLE` can mint new tokens, potentially increasing the total supply beyond the initial amount. Accounts with the `PAUSER_ROLE` can pause all token transfers, effectively freezing the token. The `DEFAULT_ADMIN_ROLE` has the power to grant and revoke these roles. While the proxy's admin is a multisig, the direct control over token mechanics remains centralized within these roles, posing a risk if compromised or misused.
FixEnsure that the `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` are assigned to trusted, multi-signature wallets or robust governance mechanisms. Clearly document the policies and procedures for exercising these powers, especially regarding minting and pausing, to maintain transparency and accountability. Consider implementing time-locks or additional governance checks for critical operations like minting large quantities or pausing.
StatusUnresolved
Low

EIP-2612 Permit Front-Running Risk

L-01The `permit` function implements EIP-2612, allowing users to approve token transfers off-chain using a signed message. While beneficial for gasless approvals, this introduces a potential front-running risk. If a signed `permit` message is broadcast or leaked before the transaction is mined, a malicious actor could front-run the transaction, submitting their own transaction with the same signed message to approve themselves as the `spender` or to approve a different `spender` for the `owner`'s tokens. The `deadline` parameter offers some mitigation but does not eliminate the risk entirely.
IssueThe `permit` function implements EIP-2612, allowing users to approve token transfers off-chain using a signed message. While beneficial for gasless approvals, this introduces a potential front-running risk. If a signed `permit` message is broadcast or leaked before the transaction is mined, a malicious actor could front-run the transaction, submitting their own transaction with the same signed message to approve themselves as the `spender` or to approve a different `spender` for the `owner`'s tokens. The `deadline` parameter offers some mitigation but does not eliminate the risk entirely.
FixEducate users about the risks associated with sharing signed `permit` messages. Advise users to set reasonable `deadline` values and to only sign messages from trusted interfaces. While this is an inherent characteristic of EIP-2612, clear user guidance can help mitigate the practical impact.
StatusUnresolved
Info

Redundant `InitializableV2` Contract

I-01The `InitializableV2` contract introduces an `isInitialized` flag and associated functions (`initialize`, `_requireIsInitialized`, `_isInitialized`). This functionality is already provided by OpenZeppelin's `Initializable` contract, which `InitializableV2` itself inherits from. While `isInitialized` is private and won't cause storage collisions with OpenZeppelin's `_initialized` variable, its presence is redundant and adds unnecessary complexity to the codebase without apparent additional benefit.
IssueThe `InitializableV2` contract introduces an `isInitialized` flag and associated functions (`initialize`, `_requireIsInitialized`, `_isInitialized`). This functionality is already provided by OpenZeppelin's `Initializable` contract, which `InitializableV2` itself inherits from. While `isInitialized` is private and won't cause storage collisions with OpenZeppelin's `_initialized` variable, its presence is redundant and adds unnecessary complexity to the codebase without apparent additional benefit.
FixConsider removing `InitializableV2` and directly inheriting `Initializable` from OpenZeppelin, ensuring proper initialization calls are made to the base `Initializable` contract. If `InitializableV2` was intended for a specific purpose beyond basic initialization, clarify its role or integrate its unique logic directly into `SuperRareToken` if minimal.
StatusUnresolved
Info

Use of Older Solidity Version (0.7.3)

I-02The contract is compiled with Solidity version 0.7.3. While functional, newer versions (e.g., 0.8.x) include important security enhancements such as default integer overflow/underflow checks, which reduce the risk of common arithmetic vulnerabilities. Although OpenZeppelin contracts for 0.7.x typically include SafeMath, custom logic might still be susceptible if not carefully handled.
IssueThe contract is compiled with Solidity version 0.7.3. While functional, newer versions (e.g., 0.8.x) include important security enhancements such as default integer overflow/underflow checks, which reduce the risk of common arithmetic vulnerabilities. Although OpenZeppelin contracts for 0.7.x typically include SafeMath, custom logic might still be susceptible if not carefully handled.
FixConsider upgrading the Solidity compiler version to 0.8.x or higher, along with updating OpenZeppelin dependencies to their corresponding versions. This would leverage built-in safety features and ensure compatibility with the latest best practices. A thorough re-audit would be required after such an upgrade.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical implementation of the SuperRareToken contract is robust, leveraging battle-tested OpenZeppelin upgradeable contracts (7.2 Code Security). The EIP-2612 permit function is correctly implemented, including nonce management and signature verification, mitigating replay attacks. A minor architectural redundancy exists with the `InitializableV2` contract, which duplicates functionality already present in OpenZeppelin's `Initializable` (7.1 Architecture). Additionally, the use of Solidity 0.7.3 means the contract does not benefit from default overflow/underflow checks present in 0.8.x (7.2 Code Security).

GovernanceHigh2/10

The contract design grants significant power to accounts holding `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, and `PAUSER_ROLE` (7.3 Access Control). The `MINTER_ROLE` allows for an increase in total token supply, while the `PAUSER_ROLE` can halt all token transfers, representing a centralized point of control (7.4 Economic). While the proxy's admin is a multisig, which is a strong control for upgrades (7.5 Governance), the operational roles within the token contract itself still carry substantial authority. Clear policies and robust governance are essential for managing these powerful roles (7.8 Operations).

UpgradesHigh1/10

The contract is designed for upgradeability using the TransparentUpgradeableProxy pattern, with the implementation inheriting from OpenZeppelin's `Initializable` contracts (7.7 Upgrades). The `init` function correctly calls the initializers of parent contracts, ensuring proper setup upon deployment. The `InitializableV2` contract, while redundant, uses a private `isInitialized` flag, preventing storage collisions with OpenZeppelin's `_initialized` variable. The proxy's admin is managed by a multisig, enhancing upgrade safety and decentralization of control over contract logic changes (7.7 Upgrades).

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 4-of-7
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

56.3% in top 10
34.0% in wallets22.3% in contracts
Effective Concentration42.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

$168.9K across 11 pairs
Uniswap v4ETHanalysed$117.5K69.5%SushiswapWETH$31.2K18.5%Uniswap v3WETH$18.7K11.1%BalancerBAL$5240.3%BalancerAAVE$5130.3%Uniswap v4USDC$4450.3%

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

Key Addresses

4 addresses
Deployer
0xea61…edcf
Unlocked LP Held By
0xdc00…f9d40x8d8a…2d6b0x906a…43d0

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (56.3% total → 42.9% effective; 34.0% in EOAs, 22.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 97.9% (independent LP — depth risk, pool = 70% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 70% of DEX liquidity)
  • 1 Medium 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
Safe Token (SAFE)High RiskLQTYHigh RiskVestra DAO (VSTR)High RiskMOMOHigh RiskDog Food Token (OISHII)High RiskCapHigh Risk

Would You Like a More Detailed Audit of SuperRare?

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

Get Detailed Audit