Quantum Audit Logo

Is Cheems Safe?

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

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

Cheems CHEEMS
0x0df0…b413
BNB Chain
Not verifiedThis 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 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The ERC20Mintable contract implements a standard ERC20 token with ownership and a designated minter role. The code is based on OpenZeppelin contracts, demonstrating good practices for security and adherence to standards. Key functionalities include token transfers, allowances, and a mechanism for the owner to set a minter who can then airdrop the initial token supply. While the contract exhibits a high degree of centralization through the owner and minter roles, this is a common design pattern for simple utility tokens and is clearly defined. No critical or high-severity technical vulnerabilities were identified.

1 Medium1 Low2 Informational
Volume 24h
$63.5K
Liquidity
$5.22M
Price
$0.000000515
Token Age
1y
Top 10 Holders
79.6%

Security Findings

1 Med1 Low2 Info
Medium

Centralized Control by Owner and Minter

M-01The contract grants significant power to the `owner` and the designated `minter` address. The `owner` can transfer ownership, set the `minter`, and withdraw any ERC20 tokens from the contract. The `minter` has exclusive control over the `airdrop` function, which is the sole mechanism for distributing the initial token supply. This centralization means that a compromise of either the owner's or minter's private key could lead to unauthorized token distribution or asset drain.
IssueThe contract grants significant power to the `owner` and the designated `minter` address. The `owner` can transfer ownership, set the `minter`, and withdraw any ERC20 tokens from the contract. The `minter` has exclusive control over the `airdrop` function, which is the sole mechanism for distributing the initial token supply. This centralization means that a compromise of either the owner's or minter's private key could lead to unauthorized token distribution or asset drain.
FixConsider implementing a multi-signature wallet for the `owner` and `minter` roles to enhance security and distribute control. For critical operations like `setMinter` or `transferOwnership`, a time-lock mechanism could be added to provide a window for community or governance intervention in case of a malicious action.
StatusUnresolved
Low

Initial Supply Minted to Contract Address

L-01The constructor mints the entire initial token supply (`_total`) to the contract's own address (`address(this)`). This design choice means that no tokens are initially assigned to the deployer or any other address. All subsequent distribution of these tokens relies entirely on the `airdrop` function, which is controlled by the `minter`. If the `minter` is not set correctly or becomes inaccessible, the initial supply could be locked within the contract.
IssueThe constructor mints the entire initial token supply (`_total`) to the contract's own address (`address(this)`). This design choice means that no tokens are initially assigned to the deployer or any other address. All subsequent distribution of these tokens relies entirely on the `airdrop` function, which is controlled by the `minter`. If the `minter` is not set correctly or becomes inaccessible, the initial supply could be locked within the contract.
FixEnsure that the `minter` address is set immediately after deployment to a trusted and secure entity. Clear documentation should be provided to users explaining this distribution mechanism and the role of the `minter` in releasing the initial supply.
StatusUnresolved
Info

Owner's Ability to Withdraw Arbitrary ERC20 Tokens

I-01The `withdraw` function allows the `onlyOwner` to transfer any specified ERC20 token from the contract's balance to an arbitrary recipient. While this function is typically included as an emergency measure to recover accidentally sent tokens, it also means that if the contract were to hold other valuable ERC20 tokens (e.g., from user deposits in a future integration), the owner would have the unilateral ability to drain them.
IssueThe `withdraw` function allows the `onlyOwner` to transfer any specified ERC20 token from the contract's balance to an arbitrary recipient. While this function is typically included as an emergency measure to recover accidentally sent tokens, it also means that if the contract were to hold other valuable ERC20 tokens (e.g., from user deposits in a future integration), the owner would have the unilateral ability to drain them.
FixAcknowledge the power granted to the owner by this function. If the contract's scope expands to hold other valuable assets, consider implementing a more granular or time-locked withdrawal mechanism, or requiring multi-signature approval for such operations.
StatusUnresolved
Info

No External General Minting Function

I-02Despite the contract being named `ERC20Mintable`, the internal `_mint` function is only called once in the constructor to establish the initial supply. There is no external function provided to mint additional tokens beyond this initial amount. The `airdrop` function only distributes existing tokens from the contract's balance. This implies a fixed total supply after deployment, which might be contrary to user expectations based on the contract name.
IssueDespite the contract being named `ERC20Mintable`, the internal `_mint` function is only called once in the constructor to establish the initial supply. There is no external function provided to mint additional tokens beyond this initial amount. The `airdrop` function only distributes existing tokens from the contract's balance. This implies a fixed total supply after deployment, which might be contrary to user expectations based on the contract name.
FixClarify the token's supply mechanism in documentation. If the intent is a fixed supply after initial distribution, consider renaming the contract to better reflect this, or explicitly state that no further minting is possible post-deployment. If future minting is desired, an `onlyMinter` or `onlyOwner` function to call `_mint` would be required.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract is built upon well-audited OpenZeppelin libraries (Context, Ownable, ERC20), which significantly reduces the risk of common vulnerabilities (7.2 Code Security). Solidity version 0.8.6 mitigates integer overflow/underflow by default, and `unchecked` blocks are used appropriately where bounds are guaranteed by prior `require` statements. The implementation of ERC20 functions adheres to the standard, ensuring predictable behavior. No reentrancy vectors or other critical technical flaws were found (7.2 Code Security).

GovernanceMedium6/10

The contract features a highly centralized access control model (7.3 Access Control). The `owner` has significant power, including the ability to transfer ownership, set the `minter` address, and withdraw any ERC20 tokens from the contract (7.8 Operations). The `minter` role, once set by the owner, has exclusive control over distributing the initial token supply via the `airdrop` function (7.4 Economic). This centralization means that compromise of the owner's or minter's private key could lead to significant loss of funds or control over token distribution (7.5 Governance).

UpgradesLow10/10

The provided contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no upgrade-specific risks such as storage collisions, initializer issues, or proxy-logic mismatches. Any changes to the contract's logic would require a new deployment.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

79.6% in top 10
65.7% in wallets13.9% in contracts
Effective Concentration71.2%

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

$7.01M across 6 pairs
Pancakeswap v3WBNBanalysed$5.22M74.4%Pancakeswap v2WBNB$1.78M25.4%Pancakeswap v3USDT$9.7K0.1%Pancakeswap v2USDT$1240.0%Pancakeswap v2GCOW$40.0%Pancakeswap v3WBNB$30.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 Burned99.1% · ≈ permanent lock
LP Locked100.0% · Dead Address, TeamFinance

Key Addresses

4 addresses
Deployer
0x5275…b3ca
Unlocked LP Held By
0x556b…d59e0xc226…ec350x20be…2978

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

What Raised This Score

3 factors
  • Top-10 concentration > 70% (79.6% total → 71.2% effective; 65.7% in EOAs, 13.9% in contracts — extreme)
  • 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

Related Audits

6 more on the record
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

Would You Like a More Detailed Audit of Cheems?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit