Quantum Audit Logo

Is New BNB Coin Safe?

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

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

New BNB Coin NNB
0xcbbc…d0d5
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium2 Informational
Volume 24h
$2.8K
Liquidity
$14.9K
Price
$0.00001606
Token Age
1y
Top 10 Holders
81.9%

Security Findings

1 Crit1 High1 Med2 Info
Critical

Permanent Token Lock via Renounce Ownership

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

Irreversible Loss of Emergency Transfer Control

H-01The `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.
IssueThe `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.
FixModify 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.
StatusUnresolved
Medium

Centralized Control Over Token Transfers

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

Initial Restricted Transfer State

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

Adherence to OpenZeppelin ERC20 Standards

I-02The `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.
IssueThe `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.
FixContinue to leverage and stay updated with battle-tested libraries and standards for core functionalities.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceMedium6/10

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.

UpgradesLow9/10

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.

Security Checklist

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

Holder Composition

81.9% in top 10
17.4% in wallets64.4% in contracts
Effective Concentration43.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

$14.9K

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 Locked100.0% · GoPlus SafeToken Locker

Key Addresses

1 addresses
Deployer
0xc897…ed8d

What Raised This Score

5 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

Related Audits

6 more on the record
XPIN Token (XPIN)Medium RiskTRADOORMedium RiskBeat Token (BEAT)Medium RiskSpaceXcoinMedium RiskGen Z (Z)Medium RiskARKMedium Risk

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