Quantum Audit Logo
Launch App

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

Is New BNB Coin Safe?

NNBBNB 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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance6/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 1 High · 1 Medium · 2 Info5
SummaryAI Copilot

The audit of the Token contract revealed a well-structured ERC20 implementation with an added owner-controlled transfer mode.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $50k
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (81.9% total → 43.2% effective; 17.4% in EOAs, 64.4% in contracts — moderate)
  • Liquidity < $50k ($14,866 across 1 pairs — thin market)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium 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
64.4%Contracts17.4%Wallets18.1%Everyone else
64.4%Contracts17.4%18.1%
ContractsWalletsEveryone elseBubble area = share of supply
81.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking64.4%
  • Walletsanonymous holders, free to sell17.4%
  • Everyone elsethe rest of the supply18.1%
Effective concentrationwhat the score reads43.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 4$14.9K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$14.9KShare of depth100.0%
LP Locked100.0% · GoPlus SafeToken Locker

Security Findings

1 Critical1 High1 Medium2 Info
Critical

Permanent Token Lock via Renounce Ownership

The Token contract initializes in MODE_TRANSFER_RESTRICTED. The setMode function, which allows changing the transfer mode, is onlyOwner. If the contract owner calls renounceOwnership() while the token is in MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED, no address will be able to call setMode(MODE_NORMAL) to enable transfers. This would permanently lock the token in a restricted state, rendering it unusable for its intended purpose.C-01

Issue

The Token contract initializes in MODE_TRANSFER_RESTRICTED. The setMode function, which allows changing the transfer mode, is onlyOwner. If the contract owner calls renounceOwnership() while the token is in MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED, no address will be able to call setMode(MODE_NORMAL) to enable transfers. This would permanently lock the token in a restricted state, rendering it unusable for its intended purpose.

Fix

Implement a mechanism to prevent renounceOwnership() if the token is not in MODE_NORMAL. Alternatively, ensure that setMode can be called by a designated role (e.g., a multi-sig) even after ownership is renounced, or remove the renounceOwnership function entirely if not intended for use.

Status

Unresolved

High

Irreversible Loss of Emergency Transfer Control

The setMode function contains the condition if (_mode != MODE_NORMAL) { _mode = v; }. This means that once the token's transfer mode is set to MODE_NORMAL, it can never be changed back to MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED. This design permanently removes the owner's ability to pause or restrict transfers in an emergency situation (e.g., a critical vulnerability in an integrated DeFi protocol), which is a significant loss of control and a potential security risk.H-01

Issue

The setMode function contains the condition if (_mode != MODE_NORMAL) { _mode = v; }. This means that once the token's transfer mode is set to MODE_NORMAL, it can never be changed back to MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED. This design permanently removes the owner's ability to pause or restrict transfers in an emergency situation (e.g., a critical vulnerability in an integrated DeFi protocol), which is a significant loss of control and a potential security risk.

Fix

Modify the setMode function to allow the owner to switch between all defined modes at any time. This would restore the ability to implement emergency pauses or restrictions if needed. For example, remove the if (_mode != MODE_NORMAL) condition.

Status

Unresolved

Medium

Centralized Control Over Token Transfers

The Token contract grants the owner address complete control over the token's transferability via the setMode function. The owner can restrict or completely halt all token transfers. While this might be an intended feature for initial setup or specific use cases, it introduces a single point of failure and a high degree of centralization, which could be a concern for decentralization-focused projects or if the owner's key is compromised.M-01

Issue

The Token contract grants the owner address complete control over the token's transferability via the setMode function. The owner can restrict or completely halt all token transfers. While this might be an intended feature for initial setup or specific use cases, it introduces a single point of failure and a high degree of centralization, which could be a concern for decentralization-focused projects or if the owner's key is compromised.

Fix

Consider decentralizing control over critical functions like setMode by implementing a multi-signature wallet for the owner address or integrating a governance mechanism (e.g., DAO) for such decisions. Clearly communicate this centralized control to users.

Status

Unresolved

Info

Initial Restricted Transfer State

The Token contract's constructor sets the initial transfer mode to MODE_TRANSFER_RESTRICTED. This means that immediately after deployment, token transfers will be reverted until the owner explicitly calls setMode(MODE_NORMAL). This is a common pattern for controlled launches but requires an explicit owner action to enable full functionality.I-01

Issue

The Token contract's constructor sets the initial transfer mode to MODE_TRANSFER_RESTRICTED. This means that immediately after deployment, token transfers will be reverted until the owner explicitly calls setMode(MODE_NORMAL). This is a common pattern for controlled launches but requires an explicit owner action to enable full functionality.

Fix

Ensure that the operational team is aware of this initial state and has a clear plan to call setMode(MODE_NORMAL) at the appropriate time. Document this behavior clearly for users and stakeholders.

Status

Unresolved

Info

Adherence to OpenZeppelin ERC20 Standards

The Token contract largely follows the well-established OpenZeppelin ERC20 implementation, including Context, Ownable, and ERC20 base contracts. This adherence to widely audited and recognized standards contributes positively to the contract's overall security posture and reduces the likelihood of common ERC20-related vulnerabilities.I-02

Issue

The Token contract largely follows the well-established OpenZeppelin ERC20 implementation, including Context, Ownable, and ERC20 base contracts. This adherence to widely audited and recognized standards contributes positively to the contract's overall security posture and reduces the likelihood of common ERC20-related vulnerabilities.

Fix

Continue to leverage and stay updated with battle-tested libraries and standards for core functionalities.

Status

Unresolved

Analysis

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

The audit of the Token contract revealed a well-structured ERC20 implementation with an added owner-controlled transfer mode. While the core ERC20 functionality is robust, significant risks were identified concerning the interaction of the transfer mode mechanism with ownership management. Specifically, the design of the setMode function and the availability of renounceOwnership introduce critical operational and economic risks, potentially leading to a permanently unusable token or loss of emergency control.

Technical7/10Low risk

The contract implements a standard ERC20 token, inheriting from OpenZeppelin's ERC20 and Ownable contracts, which generally ensures good code security (7.2). The use of unchecked blocks for arithmetic operations is appropriately guarded by require statements, preventing integer overflows/underflows. However, the custom _beforeTokenTransfer hook introduces a transfer mode mechanism (MODE_NORMAL, MODE_TRANSFER_RESTRICTED, MODE_TRANSFER_CONTROLLED) which, while functional, has a critical flaw in its setMode function (7.3). Once the token's mode is set to MODE_NORMAL, it cannot be changed back, permanently disabling emergency transfer restrictions.

Governance6/10Medium risk

The token's economic model (7.4) is heavily reliant on the owner's control over transferability. The _mode variable allows the owner to restrict or completely halt transfers, which introduces a high degree of centralization. A critical governance risk (7.5) arises from the interaction of renounceOwnership and the setMode function. If the owner renounces ownership while the token is in a restricted mode (MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED), the token will become permanently unusable for general transfers, as no one can then call setMode(MODE_NORMAL) to enable them. This represents a severe operational risk (7.8) for the token's utility.

Upgrades9/10Low risk

The contract is not designed with upgradeability patterns (e.g., proxies) (7.7). Therefore, there are no upgrade-specific risks. Any changes to the contract logic would require deploying a new contract and migrating assets.

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical operational risks associated with the setMode function and renounceOwnership.

The setMode logic should be revised to allow the owner to re-enable transfer restrictions (e.g., a pause mechanism) even after MODE_NORMAL has been activated. Additionally, consider implementing a timelock for critical owner actions or a multi-signature wallet for ownership to mitigate centralized control risks. Ensure a clear operational plan is in place for the initial state and ownership management.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0xcbbc…d0d5
Deployer0xc897…ed8d
Badge for your website
New BNB 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, 202634Low
  2. Aug 12, 202623Low

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

Related Audits

6 more on the recordAll audits
XPIN TokenXPIN · BNB Chain34LowTRADOORBNB Chain34LowBeat TokenBEAT · BNB Chain34LowSpaceXcoinBNB Chain34LowGen ZZ · BNB Chain34Low蝴蝶人生BNB Chain34Low

Would You Like a More Detailed Audit of New BNB 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