Quantum Audit Logo
Launch App

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

Is SuperVerse Safe?

SUPEREthereum
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/10Governance2/10Upgrades5/10Checks passed2 of 5Findings1 High · 1 Medium · 2 Low4
SummaryAI Copilot

The SuperFarm Token contract implements a standard ERC-20 token with a fixed supply cap and Compound-style voting delegation.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 72.0%
  • LP top3 unlocked holders = 87.7%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
45.5%Contracts8.8%Wallets45.7%Everyone else
45.5%Contracts8.8%45.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
54.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking45.5%
  • Walletsanonymous holders, free to sell8.8%
  • Everyone elsethe rest of the supply45.7%
Effective concentrationwhat the score reads27.0%
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$2.82M across 7 pairs
Show 1 more pair

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$2.69MShare of depth95.3%
Top-1 Unlocked Holder72.0%
Top-3 Unlocked87.7%
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.

Security Findings

1 High1 Medium2 Low
High

Centralized Minting Authority

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

Issue

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

Fix

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

Status

Unresolved

Medium

delegateBySig Expiry Front-running

The 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)M-01

Issue

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

Fix

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

Status

Unresolved

Low

Older Solidity Compiler Version

The 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)L-01

Issue

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

Fix

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

Status

Unresolved

Low

Lack of Emergency Pause Mechanism

The 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)L-02

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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

Governance2/10High risk

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.

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to address the centralized minting authority by implementing a multi-signature wallet or a time-locked mechanism for minting operations to enhance decentralization and transparency.

While the delegateBySig front-running is a known blockchain characteristic, users should be informed of this potential risk. For future iterations, consider upgrading to a newer Solidity compiler version to benefit from improved security features and implementing an emergency pause mechanism for operational resilience.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age5y
Contract0xe53e…0a55
Deployer0x42f7…0137
Badge for your website
SuperVerse 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. Sep 4, 202654Medium
  2. Jul 31, 202661Medium

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

Frequently Asked Questions

What is the SUPER contract address?

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

Is SuperVerse a scam?

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

Is SUPER liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $2.82M.

Who holds SUPER?

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

Related Audits

6 more on the recordAll audits
MorphoEthereum54MediumBeamEthereum54Medium00 Token00 · Ethereum54MediumIxs TokenIXS · Ethereum54MediumAlberich TokenALBRH · Ethereum54MediumSpiceSFI · Ethereum54Medium

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