Quantum Audit Logo
Launch App

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

Is Cheese Head Safe?

CHEESEBNB Chain
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
SummaryAI Copilot

The CHEESE Token contract implements a standard ERC20 token with Ownable access control.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • Liquidity < $50k
  • LP top1 unlocked holder = 78.7%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (63.8% total → 29.5% effective; 6.6% in EOAs, 57.2% in contracts — mild)
  • Liquidity < $50k ($42,662 across 2 pairs — thin market)
  • LP top1 unlocked holder = 78.7% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 1 Critical 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 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
57.2%Contracts6.6%36.2%Everyone else
57.2%Contracts6.6%36.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
63.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking57.2%
  • Walletsanonymous holders, free to sell6.6%
  • Everyone elsethe rest of the supply36.2%
Effective concentrationwhat the score reads29.5%
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$42.7K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$42.7KShare of depth100.0%
LP Burned20.8%
LP Locked20.8% · Null Address
Top-1 Unlocked Holder78.7%
Top-3 Unlocked79.2%
Unlocked LP held by
0x1e78…71400x0ed9…9706

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

Security Findings

1 Critical1 Low1 Info
Critical

Unmintable Token - Critical Functional Flaw

The _mint function, which is responsible for increasing the total supply and assigning tokens to an account, is declared as internal virtual. However, there is no public or external function within the ERC20 contract, nor is it called in the constructor, that invokes _mint. Consequently, the _totalSupply will always remain zero, and no tokens can ever be created or distributed, rendering the token completely unusable.C-01

Issue

The _mint function, which is responsible for increasing the total supply and assigning tokens to an account, is declared as internal virtual. However, there is no public or external function within the ERC20 contract, nor is it called in the constructor, that invokes _mint. Consequently, the _totalSupply will always remain zero, and no tokens can ever be created or distributed, rendering the token completely unusable.

Fix

Implement a public or owner-restricted mint function that calls _mint to allow for token creation. Alternatively, call _mint within the constructor to establish an initial token supply upon deployment.

Status

Unresolved

Low

Non-Standard Decimals Value

The decimals() function returns a fixed value of 9. While technically valid, the most common standard for ERC20 tokens is 18 decimals. Using a non-standard value like 9 can lead to display issues or misinterpretations in wallets, exchanges, and other DeFi platforms that often default to or expect 18 decimals.L-01

Issue

The decimals() function returns a fixed value of 9. While technically valid, the most common standard for ERC20 tokens is 18 decimals. Using a non-standard value like 9 can lead to display issues or misinterpretations in wallets, exchanges, and other DeFi platforms that often default to or expect 18 decimals.

Fix

Consider changing the decimals() function to return 18 for broader compatibility with existing infrastructure. If 9 decimals are intentionally desired, ensure all front-end applications and integrations are aware of and correctly handle this value.

Status

Unresolved

Info

Unused Address Library

The Address library is imported into the contract, but none of its functions (isContract, sendValue, functionCall, functionStaticCall) are called or utilized within the provided ERC20 or Ownable contract logic. Including unused libraries can slightly increase bytecode size and deployment costs without providing functional benefits.I-01

Issue

The Address library is imported into the contract, but none of its functions (isContract, sendValue, functionCall, functionStaticCall) are called or utilized within the provided ERC20 or Ownable contract logic. Including unused libraries can slightly increase bytecode size and deployment costs without providing functional benefits.

Fix

Remove the import and usage of the Address library if its functions are not required by the contract. This will optimize the contract's bytecode size.

Status

Unresolved

Analysis

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

The CHEESE Token contract implements a standard ERC20 token with Ownable access control. A critical architectural flaw prevents any tokens from being minted, rendering the contract non-functional and unusable. Other minor issues include non-standard decimal configuration and an unused library.

Technical8/10Low risk

The contract implements a standard ERC20 token with an Ownable access control pattern. It utilizes Solidity 0.8.26, benefiting from built-in overflow/underflow checks, with unchecked blocks appropriately used after explicit require checks (7.2 Code Security). The _transfer and _approve functions follow common secure patterns. However, a critical architectural flaw exists where the _mint function is internal and never called, preventing any tokens from being created (7.1 Architecture).

Governance7/10Low risk

The contract incorporates the Ownable pattern, granting a single owner control over ownership transfer and renunciation (7.3 Access Control). This centralizes administrative power. Economically, the token is designed as a standard ERC20, but the inability to mint tokens means there is no supply, which is a critical economic flaw (7.4 Economic). There are no complex governance mechanisms beyond basic ownership.

Upgrades9/10Low risk

The contract is not designed with an upgradeable proxy pattern (7.7 Upgrades). Therefore, any changes to its logic would require a redeployment and migration of assets, which is a significant operational overhead. This design choice simplifies the deployment but limits future flexibility.

Final RecommendationWhat to do about this score

Address the critical issue of the unmintable token by implementing a public or owner-controlled minting function, or by calling _mint in the constructor to establish an initial supply.

This is essential for the token to have any utility. Consider making the decimals() function configurable or adhering to the common ERC20 standard of 18 decimals for broader compatibility. Review the necessity of the Address library if its functions are not utilized within the contract to reduce bytecode size.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age9d
Contract0x696b…6666
Deployer0x3dd7…f20a
Badge for your website
Cheese Head 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, 202631Low
  2. Aug 14, 202622Low

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

Would You Like a More Detailed Audit of Cheese Head?

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