Quantum Audit Logo
Launch App

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

Is Supergemma4-26b-multimodal Safe?

SUPERGEMMABase
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
Technical8/10Governance4/10Upgrades7/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The DERC20 token contract implements an ERC20 token with voting, permit, and custom inflation and vesting mechanisms.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 88.7%
  • LP top3 unlocked holders = 99.3%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (45.2% total → 25.3% effective; 11.9% in EOAs, 33.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 88.7% (independent LP — depth risk)
  • LP top3 unlocked holders = 99.3% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
33.3%Contracts11.9%Wallets54.8%Everyone else
33.3%Contracts11.9%54.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
45.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking33.3%
  • Walletsanonymous holders, free to sell11.9%
  • Everyone elsethe rest of the supply54.8%
Effective concentrationwhat the score reads25.3%
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$170.6K across 2 pairs

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$170.5KShare of depth100.0%
Top-1 Unlocked Holder88.7%
Top-3 Unlocked99.3%
Unlocked LP held by
0xe17c…11020x8ee4…485a0x170f…7cec0x1abe…00e2

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control over Pool Funds via lockPool

The lockPool function allows the contract owner to designate a pool address and subsequently prevent any token transfers *from* that address by setting isPoolUnlocked to false. This mechanism is enforced in the _beforeTokenTransfer hook. This grants the owner the unilateral power to freeze tokens held by any contract designated as the pool, posing a significant centralization and economic risk (7.3, 7.4).H-01

Issue

The lockPool function allows the contract owner to designate a pool address and subsequently prevent any token transfers *from* that address by setting isPoolUnlocked to false. This mechanism is enforced in the _beforeTokenTransfer hook. This grants the owner the unilateral power to freeze tokens held by any contract designated as the pool, posing a significant centralization and economic risk (7.3, 7.4).

Fix

Re-evaluate the necessity of the lockPool mechanism. If this functionality is critical, consider implementing a timelock, multi-signature approval, or a more decentralized governance mechanism for its activation. Clearly document this capability and its intended use to ensure transparency for users and integrators.

Status

Unresolved

Medium

Owner's Sole Control over Inflation and Burning

The mintInflation function, while publicly callable, directs all newly minted tokens to the owner(). Additionally, the burn and updateMintRate functions are restricted to onlyOwner. This grants the owner significant, centralized control over the token's supply dynamics, including inflation and deflation, which could be exploited or lead to governance concerns (7.3, 7.4, 7.5).M-01

Issue

The mintInflation function, while publicly callable, directs all newly minted tokens to the owner(). Additionally, the burn and updateMintRate functions are restricted to onlyOwner. This grants the owner significant, centralized control over the token's supply dynamics, including inflation and deflation, which could be exploited or lead to governance concerns (7.3, 7.4, 7.5).

Fix

For core economic parameters like inflation and burning, consider transitioning to a more decentralized governance model (e.g., a DAO) or implementing a timelock for sensitive operations. This would provide transparency, introduce a delay for malicious actions, and reduce reliance on a single entity.

Status

Unresolved

Low

Missing releaseVestedTokens Function

The contract includes a VestingData struct, a getVestingDataOf mapping, and several vesting-related error messages (ReleaseAmountInvalid, VestingNotStartedYet). However, the releaseVestedTokens function, which would allow users to claim their vested tokens, is not present in the provided source code snippet. This makes the vesting mechanism incomplete or unusable as presented (7.1).L-01

Issue

The contract includes a VestingData struct, a getVestingDataOf mapping, and several vesting-related error messages (ReleaseAmountInvalid, VestingNotStartedYet). However, the releaseVestedTokens function, which would allow users to claim their vested tokens, is not present in the provided source code snippet. This makes the vesting mechanism incomplete or unusable as presented (7.1).

Fix

Ensure the complete vesting logic, including the releaseVestedTokens function, is implemented and available for users to claim their vested tokens. This function should correctly calculate and transfer available vested amounts based on vestingStart, vestingDuration, and block.timestamp.

Status

Unresolved

Info

BUSL-1.1 License Usage

The contract uses the Business Source License 1.1 (BUSL-1.1). This is a non-open-source license that typically restricts usage for a certain period (e.g., 3-5 years) before converting to an open-source license like MIT. This licensing choice might have implications for project adoption, integration, and future development depending on the specific terms (7.6).I-01

Issue

The contract uses the Business Source License 1.1 (BUSL-1.1). This is a non-open-source license that typically restricts usage for a certain period (e.g., 3-5 years) before converting to an open-source license like MIT. This licensing choice might have implications for project adoption, integration, and future development depending on the specific terms (7.6).

Fix

Be aware of the implications of BUSL-1.1. Ensure all stakeholders understand the licensing terms and their potential impact on the project's ecosystem, community engagement, and future development plans.

Status

Unresolved

Analysis

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

The DERC20 token contract implements an ERC20 token with voting, permit, and custom inflation and vesting mechanisms. It utilizes battle-tested OpenZeppelin libraries for core functionalities. The contract design centralizes significant control in the owner, particularly regarding token supply dynamics and a unique pool locking mechanism. While the code quality is generally good, the high degree of owner privilege introduces notable economic and operational risks.

Technical8/10Low risk

The contract leverages battle-tested OpenZeppelin libraries for ERC20, ERC20Votes, and ERC20Permit functionalities, enhancing code security (7.2). Custom logic for inflation and vesting appears mathematically sound, and error handling is robust. However, a significant technical risk lies in the lockPool mechanism (7.3), which allows the owner to prevent token transfers from a designated address, potentially freezing funds. The mintInflation function, while publicly callable, directs minted tokens to the owner, centralizing control over supply (7.3).

Governance4/10Medium risk

The contract exhibits a high degree of centralization, primarily due to the Ownable pattern (7.5). The owner has sole control over critical economic parameters such as the yearly mint rate, token burning, and the ability to lock/unlock the designated pool address (7.4). This lockPool functionality presents a substantial economic risk, as it grants the owner the power to unilaterally freeze tokens within a specific contract (7.4). While the inflation rate is capped at 2% (7.4), the owner's ability to control its application and the overall supply dynamics introduces a single point of failure.

Upgrades7/10Low risk

The contract is not designed as an upgradeable proxy (7.7), which simplifies its architecture and eliminates upgrade-related risks such as storage collisions or proxy implementation vulnerabilities. This provides a stable and immutable contract state. However, any future changes to the contract's logic would require a new deployment and migration of assets, which can be a complex and costly process.

Final RecommendationWhat to do about this score

To mitigate the risks associated with centralized control, consider implementing a multi-signature wallet or a decentralized autonomous organization (DAO) for the contract's ownership.

This would distribute control over critical functions like lockPool, burn, and updateMintRate, reducing the impact of a single point of failure or compromised key. For the lockPool functionality, re-evaluate its necessity; if retained, implement a timelock and a robust governance process to prevent arbitrary freezing of funds. Additionally, ensure the complete vesting mechanism is implemented and publicly available for users to claim their vested tokens.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age3mo
Contract0x572c…aba3
Deployer0x57c5…5870
Badge for your website
Supergemma4-26b-multimodal 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, 202649Medium
  2. Aug 1, 202647Medium

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

Related Audits

6 more on the recordAll audits
AvantisAVNT · Base49MediumStonxBase49MediumWhuffieWHUF · Base49MediumCoinbase Wrapped Staked ETHCBETH · Base48MediumThe Innovation GameTIG · Base48MediumMetronome Synth ETHMSETH · Base50Medium

Would You Like a More Detailed Audit of Supergemma4-26b-multimodal?

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