NIAN Info
Nian is the sub-token of the Googol Nexus ecosystem, serving as the primary medium of circulation within the network. It is used for transaction fees, RWA asset purchases, and AI service payments. Its supply is dynamically adjusted by AI to maintain value stability, supported by a three-layer mechanism: asset backing, demand-driven usage, and algorithmic regulation. Nian can be generated through Googol staking or acquired via the secondary market.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is renounced
The contract does not include owner functions that allow post-deployment modifications.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The NIAN contract implements an ERC20 token with a fixed total supply, a one-time distribution to three predefined wallets (60%/20%/20%), and no administrative or owner-controlled functionality. The contract is a custom, self-contained ERC-20 implementation without reliance on external libraries such as OpenZeppelin. While the overall design is minimal and follows common patterns on Ethereum, a few areas need attention:
- The Solidity pragma is floating (^0.8.20) rather than pinned to a specific compiler version, which may introduce compilation inconsistencies and exposure to known compiler bugs.
- The standard ERC-20 approve function is susceptible to the well-known front-running race condition, and the contract does not provide increaseAllowance or decreaseAllowance helper functions to mitigate this.
- Several state variables (name, symbol, decimals) are not declared as constant, and _totalSupply is not declared as immutable, resulting in unnecessary gas consumption on every read operation.
- The internal _mint function deviates from the standard pattern by not incrementing _totalSupply, which is harmless in this context but could cause supply accounting issues if the contract were extended or inherited.
Ownership Privileges
The contract has no owner, no admin role, and no privileged access control whatsoever. There are no functions restricted to specific addresses after deployment. The contract is fully immutable once deployed, meaning:
- No address holds any special privileges or elevated permissions.
- There is no ownership transfer mechanism or multi-signature requirement.
- No party can pause, freeze, or otherwise interfere with token transfers.
- The token distribution is hardcoded and executed entirely within the constructor at deployment time.
- No new tokens can be minted after deployment - the _mint function is internal and only called during construction.
- No tokens can be burned - there is no burn function and transfers to the zero address are explicitly blocked.
- No fees, taxes, or transfer restrictions can be imposed - the contract contains no fee mechanism of any kind.
- The contract cannot be upgraded - there is no proxy pattern, no delegatecall, and no upgradeability mechanism.
Security Features
The contract implements several positive security features:
- Built-in overflow and underflow protection via Solidity 0.8+ checked arithmetic, eliminating an entire class of common vulnerabilities.
- Zero-address validation on transfers (recipient) and approvals (spender), preventing accidental token loss to the burn address.
- No external contract calls or callbacks within transfer logic, completely eliminating reentrancy attack vectors.
- No external dependencies or imported libraries, reducing the attack surface to only the audited code and removing supply chain risk.
- Fully deterministic token distribution at deployment with no post-deployment minting or burning capability, ensuring a truly fixed supply.
- No privileged roles or admin functions, meaning no single point of compromise can alter the contract's behavior.
Note - This Audit report consists of a security analysis of the NIAN smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the NIAN team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
low Issues | 2 findings
Pending
#1 low Issue
Floating Pragma - Unspecific Solidity Version
The contract uses pragma solidity ^0.8.20, which allows compilation with any compiler version from 0.8.20 up to 0.9.0. This range includes compiler versions with known bugs such as VerbatimInvalidDeduplication, FullInlinerNonExpressionSplitArgumentEvaluationOrder, and MissingSideEffectsOnSelectorAccess. While none of these bugs directly impact this contract's logic, using an unspecified version introduces unnecessary risk. This relates to SWC-103.
Pending
#2 low Issue
ERC-20 Approve Front-Running Race Condition
The approve function directly overwrites the current allowance with the new value. This creates a known race condition (SWC-114): if a token holder approves a spender for 100 tokens and then attempts to change the allowance to 50, the spender can front-run the second approve transaction, spend the original 100, and then spend the new 50 - totaling 150 tokens instead of the intended 50. The contract lacks increaseAllowance and decreaseAllowance helper functions that mitigate this issue.
optimization Issues | 2 findings
Pending
#1 optimization Issue
State Variables Should Be Declared Constant
The state variables name, symbol, and decimals are assigned at declaration and never modified after deployment. They currently occupy storage slots, requiring an SLOAD (2100 gas cold, 100 gas warm) on every read. Declaring them as constant would embed the values directly in the bytecode, eliminating storage reads entirely and reducing gas costs for all callers over the contract's lifetime.
Pending
#2 optimization Issue
State Variable Should Be Declared Immutable
The _totalSupply variable is only assigned in the constructor and never modified afterwards. It currently occupies a full storage slot, requiring an SLOAD on every read. Declaring it as immutable would store the value in the contract bytecode instead of storage, saving approximately 2100 gas per cold read.
informational Issues | 5 findings
Pending
#1 informational Issue
Non-Standard Mint Implementation - Supply Accounting Deviation
The _mint function only updates the recipient's balance and emits a Transfer event but does not increment _totalSupply. In the current contract this is harmless because _totalSupply is pre-set before the three _mint calls and _mint is never called again. However, this deviates from the standard ERC-20 mint pattern where _mint increments _totalSupply. If the contract were inherited or _mint were exposed in a derived contract, it would create a supply accounting mismatch.
Pending
#2 informational Issue
Integer Division Rounding May Lock Dust Tokens
The constructor distributes the total supply using integer division: _totalSupply * 60 / 100, _totalSupply * 20 / 100, and _totalSupply * 20 / 100. Integer division truncates, so the sum of the three mints can be less than _totalSupply by up to 2 wei. These dust tokens would exist in _totalSupply but in no balance, making them permanently unrecoverable. For typical round deployment values this is a non-issue, but it represents an accounting imprecision.
Pending
#3 informational Issue
PUSH0 Opcode Compatibility on Non-Mainnet Chains
Solidity 0.8.20 and later compile with the Shanghai EVM target by default, which introduces the PUSH0 opcode. Some L2 chains and sidechains do not yet support PUSH0, which would cause deployment to fail on those networks. If the token is deployed exclusively on Ethereum mainnet, this is not an issue for that deployment, but it becomes relevant for any cross-chain strategy.
Pending
#4 informational Issue
Missing Zero-Address Validation for Sender in _transfer
The _transfer function validates that the recipient is not the zero address but does not validate that the sender is not the zero address. While this is unreachable in the current contract since the sender always originates from msg.sender in transfer() or is guarded by the allowance check in transferFrom(), the omission deviates from the standard OpenZeppelin ERC-20 implementation and reduces defense-in-depth.
Pending
#5 informational Issue
Magic Numbers Used Instead of Named Constants
The constructor uses hardcoded literal values (60, 20, 100) and hardcoded addresses for token distribution. Using magic numbers reduces code readability and makes it harder to verify the intended allocation logic at a glance. Named constants provide self-documenting code and reduce the risk of transcription errors.