NGold Info
Welcome to the NGOLD, where we present an innovative token that fuses advanced Blockchain technology with the strength and backing of gold, the oldest and most trusted asset in human history. NGOLD is a collaboration between Connpanny LLP, a leading UK-based technology and finance company, and Napoleon Gold Mine, a renowned gold mining company with over a decade of experience in Colombia.
Team and KYC Verification
The KYC verification for this project is currently in progress.
The team has submitted their information and verification is pending.
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.
Security Assessments
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 can mint
It is 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 can be burned
There is a function to burn tokens in the contract without any allowances.
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
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
BlackDex.sol
- The admin can update the BigBuy status and USDT amount for the user to any arbitrary value in the contract.
- The owner is able to withdraw the USDT token from the contract.
- The admin can update the MAX USDT limit to not less than 8 * 1e9 tokens.
- The admin can update the staking rate, including zero.
- The admin can update any arbitrary value in the reward percentage.
- The admin can pause/un-pause the swapping of the tokens.
- The owner can update the withdrawal wallet for USDT tokens.
- The owner can update the assambador wallet.
- The admin can update the foundation percentage.
Dex.sol
- The admin can pause/un-pause the swapping and withdraw functionality in the contract.
- The admin can update the commission rate, staking, and founding rates.
- The owner can update the fee wallet address.
- The admin can update the max snow token amount.
- The admin can withdraw USDT from the contract.
- The admin can update the MAX_BUY_LIMIT and MAX_SELL_LIMIT.
- The owner can update the w_wallet.
Embajadores.sol
- The admin can create new groups.
- The admin can group addresses.
- The admin can update group codes.
- The admin can add codes.
- The admin can remove addresses from groups.
- The admin can remove codes from groups.
- The admin can delete the group.
Funding.sol
- The owner can stake and unstake the tokens.
- The owner can withdraw tokens from the contract.
- The owner can approve tokens.
- The owner can update the withdrawal wallets.
gramOfGold.sol
- The owner can update the scheduled upgrade address.
- The admin can update the Oracle in the contract.
- The admin can pause/un-pause the swapping functionality in the contract.
OrderManager.sol
- The admin can approve the canceled orders.
- The admin can pay the usdt to the user.
p2p.sol
- The owner can pause the buy/sell functionality of the order.
- The owner can update the fee percentage.
- The owner can update the fee wallet address.
PresaleManager.sol
- The admin can pause/un-pause the presale swap functionality.
- The admin can activate the presale.
- The admin can deactivate the presale.
servicesOrders.sol
- The owner can mint tokens in a particular wallet.
- The owner can burn tokens from the wallet.
- The owner can update the fee wallet address.
- The owner can update the mint fees up to 100%.
Snow.sol
- The owner can authorize the address to mint and burn the token.
- The owner can revoke the authority to mint and burn the tokens.
- The owner can authorize mark address.
- The owner can revoke the mark address authorization.
- The owner can change the authorized refill address
- The authorized addresses can refill the amount.
- The authorized addresses can mint new tokens.
- The authorized addresses can burn tokens.
SnowStaking.sol
- The admin can pause/un-pause the staking and withdraw functionality in the contract.
- The admin can update the full-term and partial-term rates to not more than 10,000.
- The owner can withdraw the snowTokens from the contract.
- The owner can change the withdrawal wallet.
Walt.sol
- The admin can authorize/revoke the contract from the authorized contract list.
- The admin can update the percentage to not more than 25%.
- The admin can pay the usdt value to the user.
- The admin can airdrop snow tokens.
The contract is an upgradeable
Description: The deployer can replace the old contract with a new one with new features. Be aware of this, because the owner can add new features that may have a negative impact on your investments. Our team did not audit other contracts associated with the project. We recommend investors do their own research before investing.
Note - This Audit report consists of a security analysis of the NGold 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 NGold 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
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 12 findings
Resolved
#1 medium Issue
The owner can lock claim
The contract contains the functionality in which the owner of the contract can lock the claiming and withdrawal functionality in the contract for an indefinite period of time, which can lock the user funds in the contract. There must be a check where the claiming functionality should not be locked permanently in the contract.
Resolved
#2 medium Issue
Missing threshold for commission, staking and founding rates.
The setCommissionRate function allows an admin to set any arbitrary commission rate, creating risks like excessively high or invalid values. Without validation, this can disrupt operations and harm trust. To mitigate risks, implement bounds checking (e.g., require(_newRate <= 10, "Invalid rate");) to ensure values fall within acceptable ranges. Restrict rate changes by limiting adjustments to small increments. Introduce multi-signature approvals for sensitive updates or use time locks to delay changes for stakeholder review. Monitoring rate-change events with automated alerts can help detect anomalies. These measures enhance security and prevent misuse of the function.
Resolved
#3 medium Issue
Missing threshold for Max snow tokens.
The contract contains the functionality in which the admin of the contract can update any arbitrary value in the max snow token amount, including zero, which can lock the swapping functionality in the contract if the value is set to zero. There must be a threshold limit so that the value will lie at that range to exclude this risk from the contract.
Resolved
#4 medium Issue
The admin can drain USDT tokens.
The withdrawUSDT function allows the owner to withdraw USDT, potentially depleting the balance required for operations like swaps. To mitigate this, enforce a minimum reserve threshold to ensure enough USDT remains for contract functions. For example, add a check to prevent withdrawals that would reduce the balance below the required reserve.
Resolved
#5 medium Issue
Missing limits for MAX_BUY_LIMIT and MAX_SELL_LIMIT
The updateBuyLimit and updateSellLimit functions allow the admin to set new limits, but they could lead to market disruptions or manipulation if set to excessively high values. To mitigate this, implement range validation to ensure new limits are reasonable (e.g., greater than zero and within an allowed range).
Resolved
#6 medium Issue
Unnecessary Deletion of group.addresses:
Deleting group.addresses before adding new addresses can lead to an inconsistent state if the function reverts midway (e.g., due to invalid percentages). If the old addresses are removed but the new ones are not fully added, the group ends up empty, disrupting operations that rely on group.addresses. To avoid this, defer deletion of group.addresses until after all updates are completed successfully. A safer approach is to add new addresses first, verify the total percentage, and then delete the old addresses. This ensures the group is only updated when the entire operation completes without errors, maintaining consistency.
Resolved
#7 medium Issue
The owner can set fees more than 25%.
The contract contains the functionality in which the owner can set the fees to more than 25%, which is not recommended as this can cause the loss of funds for the user if the fees are set to 100%. There must be a check that the fees in the contract should not be more than 25% in the contract.
Resolved
#8 medium Issue
Missing 'isContract' check.
The contract lacks a validation check to ensure that specific parameters are contract addresses. Without this check, there is a risk that non-contract addresses (such as externally owned accounts, or EOAs) could be mistakenly set for parameters intended to reference other contracts. This could lead to failures in executing critical interactions within the contract, as EOAs do not support contract-specific functions. Implement a validation check to ensure that parameters designated as contract addresses are verified as such. This can be done using Solidity’s Address library function isContract, which checks if an address has associated contract code.
Resolved
#9 medium Issue
The owner can set mint fees upto 100%.
The contract contains the functionality in which the owner of the contract can set the mint fees up to 100%, which is not recommended as this can cause the loss of funds for the user if the value is set to 100%. There must be a check that the contract's fees should be not more than 25% in the contract.
Resolved
#10 medium Issue
Missing zero check.
The contract allows the admin to update the full-term and partial rates, including setting them to zero. If these rates are set to zero, users would receive no payout, which is not advisable. To prevent this, it is recommended to implement a minimum threshold limit, ensuring that the rates cannot be set to zero and safeguarding user payouts.
Resolved
#11 medium Issue
The owner can drain staked tokens.
The Withdraw function allows the contract owner to transfer SnowToken from the contract to a predefined address, provided the contract is not paused and has sufficient balance. While useful for emergencies, in a staking contract, misuse of this function could deplete funds needed for user rewards or withdrawals, causing system failures and loss of trust. To prevent such risks, safeguards are recommended, such as restricting withdrawals to non-staked tokens, ensuring sufficient balance for user stakes, and implementing multi-signature approvals. Additionally, transparency through events or notifications can maintain user confidence and ensure the contract operates as intended.
Resolved
#12 medium Issue
Missing percentage limits.
The setPercentage function allows the admin to update the percentage variable without any restrictions on its value. While this provides flexibility, the lack of limits poses risks, such as setting unrealistic or harmful values (e.g., extremely high or zero), which could disrupt the contract's operations. To mitigate this, it is recommended to implement boundaries, such as minimum and maximum allowable values, to ensure the percentage remains within a reasonable range.
low Issues | 14 findings
Resolved
#1 low Issue
Inefficient Search
The getCodeDetails function currently uses a nested loop to search for codes, resulting in O(n*m) complexity, which is inefficient for large datasets. Replacing the nested array with a mapping, where each code hash is directly linked to its details, allows for constant-time lookups (O(1)). This significantly improves scalability and reduces gas costs, especially for frequent lookups or large datasets. While mappings cannot be iterated directly, maintaining an auxiliary array can address this limitation if iteration is required. Overall, using mappings enhances performance and efficiency, making the function more suitable for larger and more complex data structures.
Resolved
#2 low Issue
No Exact Total Validation
The function does not enforce the total percentage to be exactly 10,000. This could result in either under or over-distribution of groupware. There must be a check to avoid this situation in the contract. Hence, Enforce totalPercentage == 10000 to ensure the entire reward is distributed without surplus or deficit.
Resolved
#3 low Issue
Redundant code
Repeated calls to snowToken.currentInitialSupply() and goldenPrice.usdtToSnow() might be costly. Also, The redundancy in the swap function arises from calculating expectedAmount and actualAmount with identical parameters. Both calculations call calculateTokenAmountWithPercentage(__amountIn, 0), which results in the same output. This repetition increases computational cost unnecessarily. To optimize, you can calculate the value once, store it in expectedAmount, and use it for both the slippage tolerance check and the final comparison. Removing the second calculation reduces gas usage and simplifies the code. This adjustment enhances efficiency without affecting the function’s logic, leading to lower transaction costs and cleaner code.
Resolved
#4 low Issue
Missing limits for usdtAmount
The contract contains the functionality in which the admin of the contract can set any arbitrary value in the USDT amount, which is not recommended as if the value is set to any excessive number, then there will be some failure in the functionality also if the value is set too low then the user will not be able to swap tokens. To enhance security and efficiency, limit admin privileges for updating usdtAmount and introduce value validation to prevent excessive or arbitrary values. Set upper and lower bounds for usdtAmount and monitor changes with event logging for transparency.
Resolved
#5 low Issue
Missing events arithmetic
It is recommended to emit all the critical parameter changes.
Resolved
#6 low 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.
Resolved
#7 low Issue
Unused state variables.
It is recommended that the unused code be removed from the contract.
Resolved
#8 low Issue
Missing emit
It is recommended to emit all the parameter changes.
Resolved
#9 low Issue
Missing emit
It is recommended to emit all the parameter changes.
Resolved
#10 low Issue
Unused state variable
It is recommended to remove all the unused code from the contract.
Resolved
#11 low Issue
Missing visibility
It is recommended to add the 'public', 'private', or 'internal' visibility during the declaration or initialization of a state variable or a mapping.
Resolved
#12 low Issue
Validation Against Market Data
If your marketplace allows users to specify _pricePerToken, you can still introduce mechanisms to ensure the price remains within reasonable bounds without losing P2P flexibility. Relying on user-provided _pricePerToken in a P2P function is suitable for decentralized marketplaces, as it supports true market dynamics and user freedom. However, it can lead to issues like market manipulation, user errors, and harm to platform reputation if prices are unrealistic. To mitigate these risks, you can validate prices against market data, warn users about extreme values, impose penalties for outlier prices, implement a reputation system for order credibility, or set expiration for unfilled orders. While flexibility is key for advanced users, incorporating safeguards ensures a balance between decentralization and marketplace integrity.
Resolved
#13 low Issue
Missing zero or dead address check.
It is recommended to check that the address cannot be set to zero or dead address.
Resolved
#14 low Issue
Unused state variable.
It is recommended to remove the unused code from the contract.
optimization Issues | 1 findings
Resolved
#1 optimization Issue
Use of pop() function.
To improve the efficiency of the claimReward function, consider replacing arrays with mappings that store rewards and release times, indexed by a user and reward ID. This eliminates costly pop() and swapping operations while enabling efficient lookup and updates. Alternatively, use lazy deletion by marking claimed rewards as "invalid" instead of rearranging arrays, reducing gas costs. For larger-scale systems, offload reward indexing to off-chain solutions like TheGraph, using on-chain events for tracking. Lastly, if rewards are highly time-sensitive, a priority queue could optimize claims based on release time. The mapping approach is most practical for scalability and gas efficiency.