Quantum Audit Logo

Is Cheese Head Safe?

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

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

Cheese Head CHEESE
0x696b…6666
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Critical1 Low1 Informational
Volume 24h
$13.4K
Liquidity
$42.7K
Price
$0.0000001338
Token Age
9d
Top 10 Holders
63.8%

Security Findings

1 Crit1 Low1 Info
Critical

Unmintable Token - Critical Functional Flaw

C-01The `_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.
IssueThe `_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.
FixImplement 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.
StatusUnresolved
Low

Non-Standard Decimals Value

L-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Info

Unused Address Library

I-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow7/10

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.

UpgradesLow9/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

63.8% in top 10
6.6% in wallets57.2% in contracts
Effective Concentration29.5%

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

$42.7K across 2 pairs
Pancakeswap v2WBNBanalysed$42.7K100.0%FstswapWBNB$60.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

LP Burned20.8%
LP Locked20.8% · Null Address
Top-1 Unlocked Holder78.7%
Top-3 Unlocked79.2%

Key Addresses

3 addresses
Deployer
0x3dd7…f20a
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.

What Raised This Score

6 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

Related Audits

6 more on the record
mubarakMedium RiskAlaya Governance Token (AGT)Medium RiskAsterMedium RiskTutorial (TUT)Medium RiskMYXMedium RiskBluwhale AI (BLUAI)Medium Risk

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