Nowa Info
NOWA is a next-generation cryptocurrency platform built on the Binance Smart Chain that leverages artificial intelligence to deliver highly accurate price predictions for digital assets.
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.
Token transfer can be locked
Owner can lock user funds with owner functions.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
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.
Ownership Privileges
- The owner can pause/unpause the staking functionality in the contract.
- The owner can set the APR up to 100%.
- The owner can update the stake claim time to any arbitrary value.
- The owner can set the start time for reward claims to any value.
- The owner can set the minimum stake amount.
- The owner can set the waiting interval between stake withdrawals.
- The owner can set the percentage of stake that can be withdrawn at each interval.
- The owner can perform an emergency withdrawal of any amount of tokens from the contract.
Note - This Audit report consists of a security analysis of the Nowa smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the Nowa 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
high Issues | 3 findings
Acknowledged
#1 high Issue
Owner Can Indefinitely Delay Withdrawals via setStakeClaimTime
The setStakeClaimTime function in the NowaStaking.sol contract grants the owner unilateral power to set and modify the stakeClaimTime at any moment. This timestamp is critical as it dictates when users are permitted to withdraw their staked tokens and accumulated rewards. The function currently lacks any restrictions, meaning the owner can change the withdrawal start time arbitrarily and repeatedly. This introduces a significant centralization risk. A malicious or compromised owner could exploit this by continuously pushing the stakeClaimTime further into the future, thereby preventing users from ever being able to access their funds and effectively holding them hostage within the contract.
Acknowledged
#2 high Issue
Owner Can Indefinitely Delay Reward Claims via setRewardClaimTime
The setRewardClaimTime function in the NowaStaking.sol contract mirrors the vulnerability found in setStakeClaimTime, granting the owner unrestricted authority to set and alter the rewardClaimTime. This timestamp is crucial for stakers as it determines the moment they can begin to claim their earned rewards. The function's lack of constraints allows the owner to change this time at will, even after the original claim period was meant to have started. This creates a significant centralization issue, where a malicious or compromised owner could repeatedly postpone the rewardClaimTime, effectively preventing users from ever accessing their staking rewards and locking them within the contract indefinitely.
Acknowledged
#3 high Issue
The owner can lock claim.
The setClaimPercent function grants the owner the ability to adjust the percentage of a user's total stake that can be withdrawn at each claim interval. The function includes a check to prevent the percentage from exceeding 100% but critically lacks a check to prevent it from being set to zero. The withdrawStake function calculates the claimableStakeAmount by multiplying the user's staked amount with claimPercent. If an owner sets claimPercent to 0, the claimableStakeAmount will always be zero. This means that while the withdrawal transaction itself may succeed, no tokens will be transferred, effectively preventing users from ever withdrawing their staked principal. This represents a significant centralization risk, as a malicious owner could trap all user funds within the contract.
medium Issues | 3 findings
Acknowledged
#1 medium Issue
Missing validation for minimum stake amount
The setMinStakeAmount function in the NowaStaking.sol contract lacks essential validation checks, creating a potential for the owner to set arbitrary and illogical staking limits. Currently, the function does not verify the _minStakeInWei input, allowing the owner to set the minimum stake amount to zero or an excessively high value. Setting the amount to zero could disrupt the contract's intended economic model, while setting it to an extremely large number could effectively halt all new staking activity. Furthermore, the contract also contains a maxStakeAmount, and there are no checks to ensure that the minStakeAmount is always less than or equal to the maxStakeAmount. This oversight could lead to a scenario where the minimum required stake is greater than the maximum allowed stake, creating a permanent lock on staking functionality.
Acknowledged
#2 medium Issue
Missing validation for claim interval
The setClaimInterval function allows the contract owner to unilaterally define the waiting period (claimInterval) required between user stake withdrawals. This function lacks any validation, permitting the owner to set the interval to any value, including an extremely large one. The withdrawStake function uses this claimInterval to check if enough time has passed since the user's last withdrawal. A malicious owner could exploit this by setting the claimInterval to a duration of hundreds or thousands of years. Consequently, the condition block.timestamp >= user.lastClaimTime + claimInterval would never be met for any practical purpose, effectively preventing all users from making subsequent withdrawals of their staked assets.
Acknowledged
#3 medium Issue
The owner can claim staked tokens
The emergencyWithdraw function is a highly privileged function, callable only by the contract owner, that allows for the withdrawal of any amount of the stakingToken up to the contract's entire balance. The function fails to account for the contract's liabilities, namely the total amount of tokens staked by users (totalStakeAmount) and the rewards owed to them. Because the only check is against the total contract balance, the owner can use this function to withdraw funds that belong to the stakers, not just surplus or administrative tokens. This creates a straightforward "rug pull" vector, where a malicious owner can drain the contract of all assets, leading to a total and irreversible loss of funds for all users who have staked their tokens.
informational Issues | 3 findings
Acknowledged
#1 informational Issue
Floating pragma solidity version.
Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.
Acknowledged
#2 informational Issue
Function that are not used (Dead code).
Remove unused code.
Acknowledged
#3 informational Issue
stake Function Allows Staking on Behalf of Arbitrary Addresses
The stake function is designed to accept a userAddress parameter, which dictates which account is credited with the staked amount, while transferring the tokens from the msg.sender (the caller). This creates a situation where the provider of the funds and the beneficiary of the stake can be two different addresses. While this could be intended as a feature to allow users to stake for others, it introduces a significant risk vector for phishing attacks. A malicious actor could create a deceptive third-party user interface (e.g., a website) that prompts a user to stake their tokens. When the user initiates the transaction, this malicious interface could secretly substitute the attacker's address into the userAddress parameter. The unsuspecting user (msg.sender) would then approve the transaction, resulting in their own tokens being staked, but with all ownership, withdrawal rights, and future rewards being credited to the attacker.