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.

On-chain security analysis — is it a scam or legit?
Is Cheese Head Safe?
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 →The CHEESE Token contract implements a standard ERC20 token with Ownable access control.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking57.2%
- Walletsanonymous holders, free to sell6.6%
- Everyone elsethe rest of the supply36.2%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x1e78…71400x0ed9…9706No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalUnmintable 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
LowNon-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
InfoUnused 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 4The 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).
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.
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202631Low
- 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