Report Date:
Sep 21, 2024
Audit Status:
Pass ✅
Audit Edition:
Detailed
Project Name:
NETOSU
Project Symbol:
NETOSU
Chain:
Ethereum
Contract Address:
0x13BEDf421376040E3567bd9462AA900FDf9115AC
Project Website:
The Team That Prepared the Report: www.audithaze.com
Conclusion:
NETOSU smart contract is safe for use in the Ethereum main network. The NETOSU smart contract found no vulnerabilities, backdoors, or scam scripts.
Smart contract information:
Contract Name: NETOSU
Compiler Version: v0.8.0+commit.7dd6d404
Optimization Enabled: Yes with 200 runs
Deploy information:
Deploy date: 2024
Owner can mint?
Refers to the creation of new tokens within the contract’s ecosystem.
No mint functionOwner can blacklist?
Refers to prohibiting specific addresses from using the contract’s ecosystem.
No blacklist foundCan be a honeypot?
Refers to a possible state of the contract where nobody can sell their assets.
No honeypot optionOwner can set fees?
Refers to the possibility of the owner setting the maximum amount of sell fee.
No high sell feesTrading enabled?
Refers to if the owner needs to take action to enable trading, or if trading is enabled already.
Trading enabledAssessment Results
Score Results
Important Notes:
Always DYOR on the project itself.
Auditor Score: 97
Audit Passed ✅
Contract Overview Checklist
The code was tested with compatible compilers and simulated manually reviewed for all commonly known and specific vulnerabilities.
Vulnerability description | Status |
---|---|
Visibility of functions and variables | Passed |
Compiler error | Passed |
ROI Investment Plan | Passed |
Transfer Block | Passed |
Floating pragma | Passed |
Timestamp dependence | Passed |
Deprecated solidity functions | Passed |
Gas limit and loops | Passed |
Front running | Passed |
User balance manipulation | Passed |
Dos with revert | Passed |
Dos with block gas limit | Passed |
Reentrancy security | Passed |
Malicious libraries | Passed |
Integer overflow/underflow | Passed |
Using inline assembly | Passed |
Missing event emission | Passed |
Missing zero address validation | Passed |
Use of tx.origin | Passed |
Oracle security | Passed |
Outdated compiler version | Passed |
Block values as a proxy for time | Passed |
Presence of unused code | Passed |
Data consistency | Passed |
Money giving bug | Passed |
Unnecessary use of SafeMath | Passed |
Self-destruct interaction | Passed |
Signature unique id | Passed |
Weak sources of randomness | Passed |
Optimize code and efficient gas fee | Passed |
Owner privileges:
The list of functions in the contract that only the owner can call.
- activateProject()
- setMaxSearchAddress()
Risk Analysis
Classifications of Manual Risk Results
Classification | Description |
---|---|
Critical | Danger or Potential Problems. |
Major | Be Careful |
Minor | Pass, Not-Detected or Safe Item. |
Informational | Function Detected |
Manual Code Review Risk Results
Contract Priviledge | Description |
---|---|
Can mint? | Pass |
Edit taxes over 25%? | Pass |
Max Tx? | Pass |
Max Wallet? | Pass |
Has to enable trading? | Pass |
Modify Tax | Pass |
Can blacklist? | Pass |
Is Honeypot? | Liquidity has not been added |
Trading Cooldown | Not Detected |
Can Pause Trade? | Pass |
Pause Transfer? | Not Detected |
Contract Privilege Description
Description | Result |
---|---|
Is Proxy? | Not Detected |
Is Anti Whale? | Not Detected |
Is Anti Bot? | Not Detected |
Is Blacklist? | Not Detected |
Blacklist Check | Pass |
Is Whitelist? | Not Detected |
Buy Tax | 0 |
Sell Tax | 0 |
Can Take Ownership? | Not Detected |
Hidden Owner? | Not Detected |
Self Destruct? | Not Detected |
Other? | Not Detected |
Other? | Not Detected |
Assessment Summary
This report has been prepared for NETOSU Token on the Ethereum network. AuditHaze provides both client-centered and user-centered examination of the smart contracts and their current status when applicable. This report represents the security assessment made to find issues and vulnerabilities on the source code along with the current liquidity and token holder statistics of the protocol.
A comprehensive examination has been performed, utilizing Cross Referencing, Static Analysis, In-House Security Tools, and line-by-line Manual Review.
The auditing process pays special attention to the following considerations:
- Testing the smart contracts against both common and uncommon attack vectors.
- Inspecting liquidity and holders statistics to inform the current status to both users and client when applicable.
- Assessing the codebase to ensure compliance with current best practices and industry standards.
- Verifying contract functions that allow trusted and/or untrusted actors to mint, lock, pause, and transfer assets.
- Cross referencing contract structure and implementation against similar smart contracts produced by industry leaders.
- Thorough line-by-line manual review of the entire codebase by industry experts.
Project Overview
Parameter | Result |
---|---|
Transfer From Owner | Pass |
Transfer From Holder | Pass |
Add Liquidity | Pass |
Remove Liquidity | Pass |
Buy from Owner | Pass |
Buy from Holder | Pass |
Sale from Owner | Pass |
Sale from Holder | Pass |
Remove Liquidity | Pass |
SwapAndLiquify | Pass |
SwapAndSale w/Fee | Pass |
SwapAndSale TX | Pass |
SwapAndSale No/Fee TX | Pass |
Parameter | Result |
---|---|
Pool Creation | Pass |
Pool Creation TX | Pool Finalize Pass |
Pool Finalize TX | Enable Pass |
KYC Information
No KYC Report
ID | Severity | Name | File Location |
---|---|---|---|
SWC-100 | Pass | Function Default Visibility | L: 0 C: 0 |
SWC-101 | Pass | Integer Overflow and Underflow | L: 0 C: 0 |
SWC-102 | Pass | Outdated Compiler Version | L: 0 C: 0 |
SWC-103 | Pass | A floating pragma is set | L: 0 C: 0 |
SWC-104 | Pass | Unchecked Call Return Value | L: 0 C: 0 |
SWC-105 | Pass | Unprotected Ether Withdrawal | L: 0 C: 0 |
SWC-106 | Pass | Unprotected SELFDESTRUCT Instruction | L: 0 C: 0 |
SWC-107 | Pass | Read of persistent state following external call | L: 0 C: 0 |
SWC-108 | Pass | State variable visibility is not set | L: 0 C: 0 |
SWC-109 | Pass | Uninitialized Storage Pointer | L: 0 C: 0 |
SWC-110 | Pass | Assert Violation | L: 0 C: 0 |
SWC-111 | Pass | Use of Deprecated Solidity Functions | L: 0 C: 0 |
SWC-112 | Pass | Delegate Call to Untrusted Callee | L: 0 C: 0 |
SWC-113 | Pass | Multiple calls are executed in the same transaction | L: 0 C: 0 |
SWC-114 | Pass | Transaction Order Dependence | L: 0 C: 0 |
SWC-115 | Pass | Authorization through tx.origin | L: 0 C: 0 |
SWC-116 | Pass | A control flow decision is made based on The block.timestamp environment variable | L: 0 C: 0 |
SWC-117 | Pass | Signature Malleability | L: 0 C: 0 |
SWC-118 | Pass | Incorrect Constructor Name | L: 0 C: 0 |
SWC-119 | Pass | Shadowing State Variables | L: 0 C: 0 |
SWC-120 | Pass | Potential use of block.number as source of randomness | L: 0 C: 0 |
SWC-121 | Pass | Missing Protection against Signature Replay Attacks | L: 0 C: 0 |
SWC-122 | Pass | Lack of Proper Signature Verification | L: 0 C: 0 |
SWC-123 | Pass | Requirement Violation | L: 0 C: 0 |
SWC-124 | Pass | Write to Arbitrary Storage Location | L: 0 C: 0 |
SWC-125 | Pass | Incorrect Inheritance Order | L: 0 C: 0 |
SWC-126 | Pass | Insufficient Gas Griefing | L: 0 C: 0 |
SWC-127 | Pass | Arbitrary Jump with Function Type Variable | L: 0 C: 0 |
SWC-128 | Pass | DoS With Block Gas Limit | L: 0 C: 0 |
SWC-129 | Pass | Typographical Error | L: 0 C: 0 |
SWC-130 | Pass | Right-To-Left-Override control character (U+202E) | L: 0 C: 0 |
SWC-131 | Pass | Presence of unused variables | L: 0 C: 0 |
SWC-132 | Pass | Unexpected Ether balance | L: 0 C: 0 |
SWC-133 | Pass | Hash Collisions with Multiple Variable Length Arguments | L: 0 C: 0 |
SWC-134 | Pass | Message call with hardcoded gas amount | L: 0 C: 0 |
SWC-135 | Pass | Code With No Effects (Irrelevant/Dead Code) | L: 0 C: 0 |
SWC-136 | Pass | Unencrypted Private Data On-Chain | L: 0 C: 0 |
We scan the contract for additional security issues using MYTHX and industry-standard security scanning tools.
ID | Severity | Name | Result | Status |
---|---|---|---|---|
$NETOSU-01 | Minor | Potential Sandwich Attacks | Pass | Not-Found |
$NETOSU-02 | Minor | Function Visibility Optimization | Pass | Not-Found |
$NETOSU-03 | Minor | Lack of Input Validation | Pass | Not-Found |
$NETOSU-04 | Major | Centralized Risk In addLiquidity | Pass | Not-Found |
$NETOSU-05 | Minor | Missing Event Emission | Pass | Not-Found |
$NETOSU-06 | Minor | Conformance with Solidity Naming Conventions | Pass | Not-Found |
$NETOSU-07 | Minor | State Variables could be Declared Constant | Pass | Not-Found |
$NETOSU-08 | Minor | Dead Code Elimination | Pass | Not-Found |
$NETOSU-09 | Major | Third Party Dependencies | Pass | Not-Found |
$NETOSU-10 | Major | Initial Token Distribution | Pass | Not-Found |
$NETOSU-11 | Major | Complexity on the tax calculations | Pass | Not-Found |
$NETOSU-12 | Major | Centralization Risks In The X Role | Pass | Not-Found |
$NETOSU-13 | Informational | Extra Gas Cost For User | Pass | Not-Found |
$NETOSU-14 | Medium | Unnecessary Use Of SafeMath | Pass | Not-Found |
$NETOSU-15 | Medium | Symbol Length Limitation due to Solidity Naming Standards | Pass | Not-Found |
$NETOSU-16 | Medium | Invalid collection of Taxes during Transfer | Pass | Not-Found |
$NETOSU-17 | Informational | Conformance to numeric notation best practice | Pass | Not-Found |
$NETOSU-18 | Informational | Enable Trade and Exclude Exist to create a whitelist | Pass | Not-Found |
Appendix
Finding Categories
Centralization / Privilege
Centralization / Privilege findings refer to either feature logic or implementation of components that act against the nature of decentralization, such as explicit ownership or specialized access roles in combination with a mechanism to relocate funds.
Gas Optimization
Gas Optimization findings do not affect the functionality of the code but generate different, more optimal EVM opcodes resulting in a reduction on the total gas cost of a transaction.
Logical Issue
Logical Issue findings detail a fault in the logic of the linked code, such as an incorrect notion on how block.timestamp works.
Control Flow
Control Flow findings concern the access control imposed on functions, such as owner-only functions being invoke-able by anyone under certain circumstances.
Volatile Code
Volatile Code findings refer to segments of code that behave unexpectedly on certain edge cases that may result in a vulnerability.
Coding Style
Coding Style findings usually do not affect the generated byte-code but rather comment on how to make the codebase more legible and, as a result, easily maintainable.
Inconsistency
Inconsistency findings refer to functions that should seemingly behave similarly yet contain different code, such as a constructor assignment imposing different require statements on the input variables than a setter function.
Coding Best Practices
ERC 20 Coding Standards are a set of rules that each developer should follow to ensure the code meet a set of criteria and is readable by all the developers.