Quantum Audit Logo
Launch App

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

Is NianNian Safe?

NIANNIANBNB 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
Technical8/10Governance9/10Upgrades9/10Checks passed7 of 7Findings1 Critical · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit of the Token contract identified a critical design flaw related to the irreversible loss of transfer control, where the owner cannot re-enable transfer restrictions once the token is set to MODE_NORMAL.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (28.6% total → 24.6% effective; 21.9% in EOAs, 6.7% in contracts — mild)
  • 1 Critical 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 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
6.7%Contracts21.9%Wallets71.4%Everyone else
6.7%21.9%Wallets71.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
28.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.7%
  • Walletsanonymous holders, free to sell21.9%
  • Everyone elsethe rest of the supply71.4%
Effective concentrationwhat the score reads24.6%
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$105.0K across 8 pairs
Show 2 more pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$97.9KShare of depth93.3%
LP Locked100.0% · GoPlus SafeToken Locker
Unlocked LP held by
0xd946…459d

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

Security Findings

1 Critical1 Medium1 Low1 Info
Critical

Irreversible Loss of Transfer Control

The setMode function contains a condition if (_mode != MODE_NORMAL) which prevents the owner from ever re-enabling transfer restrictions once the token's mode has been set to MODE_NORMAL. This means that if the owner transitions the token to MODE_NORMAL (fully unrestricted transfers), they permanently lose the ability to revert to MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED. This removes a core control mechanism designed into the contract, potentially hindering the project's ability to respond to unforeseen security incidents or market manipulations by re-imposing restrictions.C-01

Issue

The setMode function contains a condition if (_mode != MODE_NORMAL) which prevents the owner from ever re-enabling transfer restrictions once the token's mode has been set to MODE_NORMAL. This means that if the owner transitions the token to MODE_NORMAL (fully unrestricted transfers), they permanently lose the ability to revert to MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED. This removes a core control mechanism designed into the contract, potentially hindering the project's ability to respond to unforeseen security incidents or market manipulations by re-imposing restrictions.

Fix

Modify the setMode function to allow the owner to transition between all defined modes (MODE_NORMAL, MODE_TRANSFER_RESTRICTED, MODE_TRANSFER_CONTROLLED) without permanent restrictions. For example, remove the if (_mode != MODE_NORMAL) condition to allow _mode to be set to any valid value at any time by the owner.

Status

Unresolved

Medium

Highly Centralized Transfer Control

The _mode mechanism, specifically MODE_TRANSFER_CONTROLLED, allows only transfers where either the from or to address is the contract owner. This design choice makes the token highly centralized, as general users cannot freely transfer tokens among themselves. This significantly limits the token's utility, liquidity, and decentralization, concentrating power and control in the hands of the owner.M-01

Issue

The _mode mechanism, specifically MODE_TRANSFER_CONTROLLED, allows only transfers where either the from or to address is the contract owner. This design choice makes the token highly centralized, as general users cannot freely transfer tokens among themselves. This significantly limits the token's utility, liquidity, and decentralization, concentrating power and control in the hands of the owner.

Fix

Evaluate if such a high degree of centralization aligns with the project's long-term vision. If a more decentralized model is desired, consider removing or modifying the MODE_TRANSFER_CONTROLLED state to allow broader transferability. Clearly communicate these transfer restrictions to all potential users and investors.

Status

Unresolved

Low

Initial Transfer Restriction Requires Owner Action

The token contract is initialized in MODE_TRANSFER_RESTRICTED in its constructor. This means that immediately after deployment, no token transfers are possible until the contract owner explicitly calls the setMode function to change it to MODE_NORMAL or MODE_TRANSFER_CONTROLLED. This introduces an operational dependency on the owner to perform an additional transaction post-deployment to enable basic token functionality.L-01

Issue

The token contract is initialized in MODE_TRANSFER_RESTRICTED in its constructor. This means that immediately after deployment, no token transfers are possible until the contract owner explicitly calls the setMode function to change it to MODE_NORMAL or MODE_TRANSFER_CONTROLLED. This introduces an operational dependency on the owner to perform an additional transaction post-deployment to enable basic token functionality.

Fix

Ensure that the contract owner is aware of this initial state and is prepared to execute the setMode transaction promptly after deployment if immediate transferability is desired. Alternatively, consider initializing the token in MODE_NORMAL if unrestricted transfers are the default intended behavior.

Status

Unresolved

Info

Standard unchecked Usage for Arithmetic Operations

The contract utilizes unchecked blocks for arithmetic operations such as _balances[from] = fromBalance - amount; and _balances[to] += amount;. These operations are preceded by require statements that ensure conditions like fromBalance >= amount are met, effectively preventing underflow. For additions, overflow is practically not an issue with uint256 for typical token supplies. This is a standard and secure pattern in modern Solidity to optimize gas costs while maintaining safety.I-01

Issue

The contract utilizes unchecked blocks for arithmetic operations such as _balances[from] = fromBalance - amount; and _balances[to] += amount;. These operations are preceded by require statements that ensure conditions like fromBalance >= amount are met, effectively preventing underflow. For additions, overflow is practically not an issue with uint256 for typical token supplies. This is a standard and secure pattern in modern Solidity to optimize gas costs while maintaining safety.

Fix

No action required. This is a secure and gas-efficient practice.

Status

Resolved

Analysis

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

The audit of the Token contract identified a critical design flaw related to the irreversible loss of transfer control, where the owner cannot re-enable transfer restrictions once the token is set to MODE_NORMAL. Additionally, the contract exhibits a high degree of centralization in transfer control and requires immediate owner action post-deployment to enable transfers. The core ERC20 implementation is robust, leveraging standard OpenZeppelin patterns.

Technical8/10Low risk

The contract implements a standard ERC20 token with custom transfer logic. It correctly uses OpenZeppelin's Ownable pattern for access control and unchecked blocks for arithmetic operations where safety is guaranteed by prior checks (7.2 Code Security). The custom _beforeTokenTransfer hook effectively enforces the defined transfer modes (7.1 Architecture). However, the setMode function contains a critical flaw that prevents re-enabling transfer restrictions once MODE_NORMAL is set, limiting future operational flexibility (7.3 Access Control).

Governance9/10Low risk

The token's economic model is highly centralized, with the owner having significant control over transferability through the _mode mechanism (7.4 Economic). The MODE_TRANSFER_CONTROLLED state restricts transfers to only involve the owner, severely impacting liquidity and decentralization (7.4 Economic). A critical governance risk exists where the owner permanently loses the ability to re-impose transfer restrictions once MODE_NORMAL is activated, potentially compromising the project's ability to respond to future security or market events (7.5 Governance).

Upgrades9/10Low risk

The contract is not designed with an upgradeability pattern (7.7 Upgrades). This means its logic cannot be modified or updated after deployment. Any changes or bug fixes would require a new contract deployment and a migration of assets, which is a significant operational undertaking. This design choice implies immutability post-deployment.

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical issue regarding the irreversible loss of transfer control.

The setMode function should be modified to allow the owner to transition between all defined modes as needed, providing necessary operational flexibility. Consider whether the high degree of centralization in transfer control aligns with the project's long-term decentralization goals and communicate these limitations clearly to users. Ensure the owner is prepared to execute the initial setMode transaction promptly after deployment to enable token transfers.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x9c27…c096
Deployer0xc301…fea2
Badge for your website
NianNian 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, 202613Low
  2. Aug 31, 202614Low

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

Frequently Asked Questions

What is the NIANNIAN contract address?

The NianNian contract on BNB Chain is 0x9c27c4072738cf4b7b0b7071af0ad5666bddc096. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is NianNian a scam?

Quantum Audit's risk score for NianNian is 13/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is NIANNIAN liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $105.0K.

Who holds NIANNIAN?

As of Sep 4, 2026, the 10 largest holders own 28.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
FrippyBNB Chain13LowGiggle MascotMAX · BNB Chain13LowOKZOOAIOT · BNB Chain13LowBinance CatBNBCAT · BNB Chain13LowARIA.AIARIA · BNB Chain12LowBreak And ReclaimBAN · BNB Chain14Low

Would You Like a More Detailed Audit of NianNian?

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