Quantum Audit Logo

Is NianNian Safe?

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

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

NianNian NIANNIAN
0x9c27…c096
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive 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`. 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.

1 Critical1 Medium1 Low1 Informational
Volume 24h
$50.4K
Liquidity
$97.9K
Price
$0.0007034
Token Age
1y
Top 10 Holders
28.6%

Security Findings

1 Crit1 Med1 Low1 Info
Critical

Irreversible Loss of Transfer Control

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

Highly Centralized Transfer Control

M-01The `_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.
IssueThe `_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.
FixEvaluate 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.
StatusUnresolved
Low

Initial Transfer Restriction Requires Owner Action

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

Standard `unchecked` Usage for Arithmetic Operations

I-01The 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.
IssueThe 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.
FixNo action required. This is a secure and gas-efficient practice.
StatusResolved

Category Ratings

TechnicalLow8/10

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).

GovernanceLow9/10

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).

UpgradesLow9/10

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.

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

28.6% in top 10
21.9% in wallets6.7% in contracts
Effective Concentration24.6%

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

$105.0K across 8 pairs
Pancakeswap v3WBNBanalysed$97.9K93.3%Pancakeswap v3U$6.5K6.2%Pancakeswap v2YXL$5060.5%Pancakeswap v3U$270.0%Pancakeswap v2TUT$130.0%TopazWBNB$70.0%
Show 2 more pairsShow less
Pancakeswap v2Subject 3$20.0%Pancakeswap v2SHIB$20.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 Locked100.0% · GoPlus SafeToken Locker

Key Addresses

2 addresses
Deployer
0xc301…fea2
Unlocked LP Held By
0xd946…459d

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

What Raised This Score

4 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

Related Audits

6 more on the record
FrippyLow RiskGiggle Mascot (MAX)Low RiskOKZOO (AIOT)Low RiskBinance Cat (BNBCAT)Low RiskARIA.AI (ARIA)Low RiskBuild On BNB (BOB)Low Risk

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