Quantum Audit Logo

Is SuperVerse Safe?

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

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

SuperVerse SUPER
0xe53e…0a55
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The SuperFarm Token contract implements a standard ERC-20 token with a fixed supply cap and Compound-style voting delegation. It leverages OpenZeppelin contracts for core ERC-20 and access control functionalities. The audit identified a high-severity centralization risk related to token minting and a medium-severity concern regarding front-running in signature-based delegation. Several low-severity and informational findings were also noted, primarily concerning operational flexibility and compiler version.

1 High1 Medium2 Low
Volume 24h
$126.6K
Liquidity
$2.69M
Price
$0.1146
Token Age
5y
Top 10 Holders
54.3%

Security Findings

1 High1 Med2 Low
High

Centralized Minting Authority

H-01The `mint` function is restricted to the contract owner, allowing them to mint tokens up to the predefined cap. This grants significant control over the token supply and distribution, which could influence governance outcomes if the owner mints tokens to themselves or allied addresses without proper oversight. (7.3 Access Control, 7.4 Economic)
IssueThe `mint` function is restricted to the contract owner, allowing them to mint tokens up to the predefined cap. This grants significant control over the token supply and distribution, which could influence governance outcomes if the owner mints tokens to themselves or allied addresses without proper oversight. (7.3 Access Control, 7.4 Economic)
FixConsider implementing a multi-signature wallet for ownership of the `mint` function or a time-locked mechanism for minting operations. This would decentralize control and increase transparency, reducing the risk of a single point of failure or malicious action.
StatusUnresolved
Medium

`delegateBySig` Expiry Front-running

M-01The `delegateBySig` function uses `now <= expiry` to check signature validity. This check is susceptible to miner front-running, where a malicious miner could manipulate transaction inclusion order to cause a valid signature to expire or an expired signature to be included, within the same block. (7.2 Code Security, 7.6 External)
IssueThe `delegateBySig` function uses `now <= expiry` to check signature validity. This check is susceptible to miner front-running, where a malicious miner could manipulate transaction inclusion order to cause a valid signature to expire or an expired signature to be included, within the same block. (7.2 Code Security, 7.6 External)
FixWhile this is a common pattern and a general characteristic of blockchain transactions, users should be aware of this potential front-running risk for time-sensitive delegation. For critical operations, consider alternative mechanisms or ensure users understand the implications.
StatusUnresolved
Low

Older Solidity Compiler Version

L-01The contract uses Solidity 0.6.12. While functional and compatible with OpenZeppelin 3.x, newer versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, reducing reliance on SafeMath libraries and potentially simplifying code while enhancing security. (7.2 Code Security)
IssueThe contract uses Solidity 0.6.12. While functional and compatible with OpenZeppelin 3.x, newer versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, reducing reliance on SafeMath libraries and potentially simplifying code while enhancing security. (7.2 Code Security)
FixConsider upgrading to a more recent Solidity compiler version (e.g., 0.8.x) for future deployments or significant updates to benefit from improved security features, optimizations, and reduced bytecode size. Ensure thorough testing if upgrading.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-02The contract lacks a mechanism to pause critical operations (e.g., transfers, minting) in case of an emergency, such as a discovered vulnerability in the token itself or a major external exploit impacting the ecosystem. This limits the ability to react swiftly to unforeseen events. (7.8 Operations)
IssueThe contract lacks a mechanism to pause critical operations (e.g., transfers, minting) in case of an emergency, such as a discovered vulnerability in the token itself or a major external exploit impacting the ecosystem. This limits the ability to react swiftly to unforeseen events. (7.8 Operations)
FixFor future iterations, consider implementing a `Pausable` mechanism (e.g., from OpenZeppelin) controlled by a multi-signature wallet or governance. This would provide an emergency stop-gap to mitigate damage in critical situations.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract is built upon battle-tested OpenZeppelin libraries (ERC20Capped, Ownable), which enhances its foundational security (7.2 Code Security). The voting mechanism is a well-understood pattern adapted from Compound. However, the use of Solidity 0.6.12 is an older version, lacking built-in overflow checks (7.2 Code Security). The `delegateBySig` function's `now <= expiry` check is susceptible to miner front-running (7.6 External).

GovernanceHigh2/10

The token features a fixed supply cap, preventing inflationary attacks beyond the initial design (7.4 Economic). The voting delegation mechanism is standard, promoting decentralized governance participation. A significant risk is the centralized control over token minting, as the `mint` function is `onlyOwner`, allowing the owner to control token distribution up to the cap (7.3 Access Control). This could impact governance dynamics if not managed transparently.

UpgradesMedium5/10

The contract is not designed to be upgradeable. This simplifies the architecture by removing the complexities and risks associated with proxy patterns (7.7 Upgrades). However, it means that any future bug fixes, feature additions, or protocol changes would require a new contract deployment and a migration process for token holders.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

54.3% in top 10
8.8% in wallets45.5% in contracts
Effective Concentration27.0%

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

$2.82M across 7 pairs
Uniswap v2WETHanalysed$2.69M95.3%SupernovaUSDT$79.9K2.8%Uniswap v3WETH$32.2K1.1%SushiswapWETH$13.0K0.5%Uniswap v3WETH$4.1K0.1%Uniswap v4ETH$2.1K0.1%
Show 1 more pairShow less
Sushiswap v3WETH$710.0%

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 Holder72.0%
Top-3 Unlocked87.7%

Key Addresses

11 addresses
Deployer
0x42f7…0137
Unlocked LP Held By
0x2ead…fc3e0xf35a…62070x5a35…1d010xe10e…b32e0x0c51…ebad0xf24e…96910x9978…5bbd0x24f4…ccee0x7838…adfc0x3aff…4cc3

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 NOT renounced — owner is an EOA (single private key)
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 20% (54.3% total → 27.0% effective; 8.8% in EOAs, 45.5% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 72.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 87.7% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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
MorphoHigh RiskBeamHigh Risk00 Token (00)High RiskIxs Token (IXS)High RiskAlberich Token (ALBRH)High RiskSpice (SFI)High Risk

Would You Like a More Detailed Audit of SuperVerse?

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

Get Detailed Audit