Quantum Audit Logo
Launch App

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

Is USELESS COIN Safe?

USELESSBNB 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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance5/10Upgrades6/10Checks passed5 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The BurnMintERC20 token contract implements a standard ERC20 token with additional minting and burning capabilities, leveraging OpenZeppelin's AccessControl for role management.

Read the full analysis
What raised the score
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.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
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (88.8% total → 39.9% effective; 7.4% in EOAs, 81.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.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 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
81.4%Contracts7.4%Wallets11.2%Everyone else
81.4%Contracts7.4%11.2%
ContractsWalletsEveryone elseBubble area = share of supply
88.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking81.4%
  • Walletsanonymous holders, free to sell7.4%
  • Everyone elsethe rest of the supply11.2%
Effective concentrationwhat the score reads39.9%
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$706.6K across 4 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$706.0KShare of depth99.9%
Top-1 Unlocked Holder98.7%
Top-3 Unlocked99.3%
Unlocked LP held by
0x0cd0…6e1e0x556b…d59e0x966d…e41a0xa80e…61f00x8e40…16f80x1190…f6bf0xe139…cae10xc64f…406d0x3443…10b60xce13…f41c

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 of Token Supply (Mint/Burn Roles)

The DEFAULT_ADMIN_ROLE has the sole authority to grant MINTER_ROLE and BURNER_ROLE. Holders of these roles can mint new tokens (up to i_maxSupply) or burn existing tokens. If the DEFAULT_ADMIN_ROLE is compromised or misused, it could lead to arbitrary manipulation of the token supply, directly impacting the token's value and the economic stability of the protocol (7.3, 7.4, 7.5).H-01

Issue

The DEFAULT_ADMIN_ROLE has the sole authority to grant MINTER_ROLE and BURNER_ROLE. Holders of these roles can mint new tokens (up to i_maxSupply) or burn existing tokens. If the DEFAULT_ADMIN_ROLE is compromised or misused, it could lead to arbitrary manipulation of the token supply, directly impacting the token's value and the economic stability of the protocol (7.3, 7.4, 7.5).

Fix

Implement a robust, decentralized, or multi-signature governance mechanism for the DEFAULT_ADMIN_ROLE. Consider a timelock for critical operations like granting MINTER_ROLE or BURNER_ROLE to provide a window for community review and intervention. Ensure that the addresses holding MINTER_ROLE and BURNER_ROLE are also secured by strong access control policies.

Status

Unresolved

Medium

Undefined External Dependency for s_ccipAdmin Role

The contract defines an s_ccipAdmin state variable and an interface IGetCCIPAdmin to expose it, with the DEFAULT_ADMIN_ROLE able to set this address. However, the specific functionality and security implications of this s_ccipAdmin role are not defined within this contract and depend entirely on external CCIP systems (7.6). Misconfiguration or vulnerabilities in these external systems could indirectly affect the protocol's security or operations.M-01

Issue

The contract defines an s_ccipAdmin state variable and an interface IGetCCIPAdmin to expose it, with the DEFAULT_ADMIN_ROLE able to set this address. However, the specific functionality and security implications of this s_ccipAdmin role are not defined within this contract and depend entirely on external CCIP systems (7.6). Misconfiguration or vulnerabilities in these external systems could indirectly affect the protocol's security or operations.

Fix

Provide comprehensive documentation detailing the intended use, responsibilities, and security model of the s_ccipAdmin role and its interaction with external CCIP systems. Conduct a thorough security review of any external contracts or protocols that rely on this getCCIPAdmin function to understand the full attack surface.

Status

Unresolved

Low

Initial Centralization of DEFAULT_ADMIN_ROLE

The constructor assigns the DEFAULT_ADMIN_ROLE to msg.sender (the deployer). While common, this means that immediately after deployment, a single external owned account (EOA) holds complete administrative control over the contract (7.3, 7.8). If this EOA's private key is compromised before the role is transferred, the entire access control system could be subverted.L-01

Issue

The constructor assigns the DEFAULT_ADMIN_ROLE to msg.sender (the deployer). While common, this means that immediately after deployment, a single external owned account (EOA) holds complete administrative control over the contract (7.3, 7.8). If this EOA's private key is compromised before the role is transferred, the entire access control system could be subverted.

Fix

It is a best practice to transfer the DEFAULT_ADMIN_ROLE to a secure, multi-signature wallet or a robust governance contract immediately after deployment. This reduces the single point of failure risk associated with a single EOA.

Status

Unresolved

Info

Prevention of Self-Transfers/Approvals

The _transfer and _approve functions explicitly revert if the recipient or spender is address(this). This is a good security practice (7.2) that prevents tokens from being accidentally or maliciously sent to or approved by the contract itself, which could lead to tokens becoming unrecoverable or misused within the contract's balance.I-01

Issue

The _transfer and _approve functions explicitly revert if the recipient or spender is address(this). This is a good security practice (7.2) that prevents tokens from being accidentally or maliciously sent to or approved by the contract itself, which could lead to tokens becoming unrecoverable or misused within the contract's balance.

Fix

No action required. This is a positive security measure.

Status

Resolved

Analysis

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

The BurnMintERC20 token contract implements a standard ERC20 token with additional minting and burning capabilities, leveraging OpenZeppelin's AccessControl for role management. Key strengths include the use of battle-tested libraries, an immutable maximum supply, and explicit checks to prevent self-transfers. However, the contract exhibits a high degree of centralization, particularly concerning the DEFAULT_ADMIN_ROLE's power to manage minter and burner roles, which directly impacts token supply. The purpose and security implications of the s_ccipAdmin role, an external dependency, are also not fully defined within this contract.

Technical7/10Low risk

The contract leverages battle-tested OpenZeppelin libraries for ERC20, burning, and access control, enhancing code security (7.2). It implements robust checks to prevent tokens from being sent to or approved by the contract itself, improving operational safety. However, the s_ccipAdmin role's functionality is not defined within this contract, posing an external dependency risk (7.6) whose security implications are unclear. The use of AccessControl provides a clear framework for managing roles.

Governance5/10Medium risk

The token's economic model benefits from an immutable maxSupply (7.4), preventing uncontrolled inflation beyond a set limit. However, the DEFAULT_ADMIN_ROLE holds significant power, including the ability to grant MINTER_ROLE and BURNER_ROLE (7.5). This centralized control over token supply manipulation (minting up to maxSupply and burning) represents a high governance and economic risk (7.4, 7.5) if the admin key is compromised or misused. Initial deployment also places DEFAULT_ADMIN_ROLE solely with the deployer.

Upgrades6/10Medium risk

The contract is not designed to be upgradeable (7.7), which eliminates risks associated with proxy patterns and upgradeability mechanisms. This simplifies the architecture and reduces the attack surface related to upgrade logic. Consequently, there are no upgrade safety issues to address.

Final RecommendationWhat to do about this score

To mitigate the identified risks, it is strongly recommended to implement a robust governance mechanism for the DEFAULT_ADMIN_ROLE.

This should ideally involve transferring the role to a multi-signature wallet or a time-locked governance contract immediately after deployment. Additionally, thoroughly document and secure the external systems interacting with the s_ccipAdmin role, ensuring its intended function aligns with the overall security posture of the protocol.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0xba38…6d2b
Deployer0x92c9…9fc1
Badge for your website
USELESS COIN 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

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

Related Audits

6 more on the recordAll audits
CRYSTAL STONESBNB Chain49MediumEthereum TokenETH · BNB Chain49MediumPepeBNB Chain49MediumBSquared TokenB2 · BNB Chain48MediumBrokBNB Chain48Mediumo1.exchangeO · BNB Chain50Medium

Would You Like a More Detailed Audit of USELESS COIN?

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