MUSE daoMUSEdao Whitepaper
MUSE daoMUSE dao Progress Update
Holy moly, it’s been a week. MUSE dao has now officially sold out of Founding Member tokens, and our Early Adaptor launch has been a success thus far. Eight founding members have claimed their whitelist spot at 0.05 ETH, and five have been sold at the introductory public sale price of 0.1 ETH. The launch is on a sliding price scale, with the price increasing as the floor gets bought out. There are still many Early Adaptor tokens available on our OpenSea.MUSEdao Early Adaptor TokenIn the meant...
MUSE daoNFT World 2022 Plan (Introducing Virtual Nature Preservation!)
With the upcoming launch of NFT Worlds multiplayer on the horizon, the time is now to begin establishing the framework of our NFT World. Our original vision for the plan is to ensure all MUSEdao members are airdropped a piece of private real estate within the NFT World. Since then, the vision has only become grander, with utilities never seen before in the NFT space. This article shall serve as the primary document and source of truth for the MUSEdao NFT World development project. Going forwa...
MUSE.eth is a collective of entrepreneurs, artists, programmers, and makers seeking to revolutionize the human experience of art.
MUSE daoMUSEdao Whitepaper
MUSE daoMUSE dao Progress Update
Holy moly, it’s been a week. MUSE dao has now officially sold out of Founding Member tokens, and our Early Adaptor launch has been a success thus far. Eight founding members have claimed their whitelist spot at 0.05 ETH, and five have been sold at the introductory public sale price of 0.1 ETH. The launch is on a sliding price scale, with the price increasing as the floor gets bought out. There are still many Early Adaptor tokens available on our OpenSea.MUSEdao Early Adaptor TokenIn the meant...
MUSE daoNFT World 2022 Plan (Introducing Virtual Nature Preservation!)
With the upcoming launch of NFT Worlds multiplayer on the horizon, the time is now to begin establishing the framework of our NFT World. Our original vision for the plan is to ensure all MUSEdao members are airdropped a piece of private real estate within the NFT World. Since then, the vision has only become grander, with utilities never seen before in the NFT space. This article shall serve as the primary document and source of truth for the MUSEdao NFT World development project. Going forwa...
MUSE.eth is a collective of entrepreneurs, artists, programmers, and makers seeking to revolutionize the human experience of art.
Share Dialog
Share Dialog
Subscribe to MUSE dao
Subscribe to MUSE dao
<100 subscribers
<100 subscribers
Prepared for: MUSE dao - 7 March, 2022. Link to smart contract on Rinkeby Testnet:
https://rinkeby.etherscan.io/address/0x3468F18F24D4B29e130c7dfe466b20bA887904C0#code
Disclaimer
Introduction
Project information
List of attacks checked
Severity Definitions
Good things in code
Critical vulnerabilities in code
Medium vulnerabilities in code
Low vulnerabilities in code
Summary
THIS AUDIT REPORT WILL CONTAIN CONFIDENTIAL INFORMATION ABOUT THE SMART CONTRACT AND INTELLECTUAL PROPERTY OF THE CUSTOMER AS WELL AS INFORMATION ABOUT POTENTIAL VULNERABILITIES OF THEIR EXPLOITATION. THE INFORMATION FROM THIS AUDIT REPORT CAN BE USED INTERNALLY BY THE CUSTOMER OR IT CAN BE DISCLOSED PUBLICLY AFTER ALL VULNERABILITIES ARE FIXED - THE DECISION OF THE CUSTOMER. Disclaimer: The smart contracts given for audit have been analyzed in accordance with the best industry practices at the date of this report, in relation to cybersecurity vulnerabilities and issues in smart contract source code, the details of which are disclosed in t his report, (Source Code); the Source Code compilation, deployment, and functionality (performing the intended functions). Because the total numbers of test cases are unlimited, the audit makes no statements or warranties on the security of the code. It also cannot be considered as a sufficient assessment regarding the utility and safety of the code, bugfree status, or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only we recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts. Smart contracts are deployed and executed on a blockchain platform. The platform, its programming language, and other software related to the smart contract can have their own vulnerabilities that can lead to hacks. Thus, the audit can’t guarantee explicit security of the audited smart contracts.
Consultant was contacted by MUSE dao (Customer) to conduct a Smart Contracts Code Review and Security Analysis. This report presents the findings of the security assessment of Customer`s smart contracts and its code review conducted between 05/03/2022 – 09/03/2022. The project has 1 file. It contains approximately 870 lines of Solidity code. All the functions and state variables are well commented on using the natspec documentation, but that does not create any vulnerability.
Token Name: Thoth
Token Symbol: Thoth
Platform: Ethereum
Audit Started Date: 05/03/2022
Audit Completed Date: 09/03/2022
Over and under flows
Short address attack
Visibility & Delegate call
Reentrancy / TheDAO hack
Forcing Ethereum to a contract
Timestamp Dependence
Gas Limit and Loops
DoS with (Unexpected) Throw
DoS with Block Gas Limit
Transaction-Ordering Dependence
Byte array vulnerabilities
Style guide violation
Transfer forwards all gas
ERC20 API violation
Malicious libraries
Compiler version not fixed
Unchecked external call - Unchecked math
Unsafe type inference
Here you are checking that balance of contract is bigger or equal to amount and transfer to recipient is successfully done or not.
Here you are checking that balance of contract is bigger or equal to value and target address is contract address or not.
Here you are checking that owner address is valid and proper or not.
Here you are checking that to address is not same as owner address, msg.sender is owner or not, or msg.sender has allowance for transfer.
Here you are checking that to address is valid and proper, and tokenId exists or not.
Here you are checking that token is available in from address or not, to address is valid and proper, or not.
Here you are checking that newOwner address is valid and proper or not.
Here you are checking that _add value is proper and valid address or not.
Here you are checking that tokenMinted value should be smaller than MAX_NFT_SUPPLY.
Here you are checking that mint is paused or not, tokenMinted should be smaller than MAX_NFT_SUPPLY.
Here you are checking that _cnt value is bigger than 0, mint is not paused, tokenMinted should be smaller than MAX_NFT_SUPPLY, sufficient eth is given, msg.sender is whitelisted for presale, and _cnt value is smaller than or equal to 5 for presale and _cnt value is 10 for public sale.
Here you are checking that sale and reveal is ongoing or not.
No Critical vulnerabilities found
No Medium vulnerabilities found
9.1. Compiler version is not fixed:
In this file you have put “pragma solidity ^0.8.0;” which is not a good way to define compiler version. Solidity source files indicate the versions of the compiler they can be compiled with. Pragma solidity ^0.8.0; // bad: compiles 0.8.0 and above pragma solidity 0.8.0; //good: compiles 0.8.0 only. If you put(>=) symbol then you are able to get compiler version 0.8.0 and above. But if you don’t use(^/>=) symbol then you are able to use only 0.8.0 version. And if there are some changes come in the compiler and you use the old version then some issues may come at deploy time.
9.2. Suggestions to add code validations:
You have implemented required validation in contract. There are some place where you can improve validation and security of your code. These are all just suggestion it is not bug.
No use of safeMath library
Function: _burn. Here in _burn method you can check that owner has sufficient balance or not.
Function: - setWhitelist. Here in your contract you are only able to make whitelisted to address but there is not a functionality which can remove address from whitelist. o So if you want to remove any address from whitelist in future then owner is not able to do it.
Function: - withdraw. here in withdraw method you can check that transfer to ownerAddress is successfully done or not.
Function: - setPrice. Here in setPrice methods you can check that priceextended value is bigger than 0.
Number of problems in the smart contract as per severity level:
High: 0
Medium: 0
Low: 6
According to the assessment, the smart contract code is well secured. The code is written with all validation and all security is implemented. Code is performing well and there is no way to steal funds from this contract. Good Point: Code performance and quality are good. Address validation and value validation is done properly.
Suggestions: Please try to use static solidity version, and try to implement suggested code validations.
Prepared for: MUSE dao - 7 March, 2022. Link to smart contract on Rinkeby Testnet:
https://rinkeby.etherscan.io/address/0x3468F18F24D4B29e130c7dfe466b20bA887904C0#code
Disclaimer
Introduction
Project information
List of attacks checked
Severity Definitions
Good things in code
Critical vulnerabilities in code
Medium vulnerabilities in code
Low vulnerabilities in code
Summary
THIS AUDIT REPORT WILL CONTAIN CONFIDENTIAL INFORMATION ABOUT THE SMART CONTRACT AND INTELLECTUAL PROPERTY OF THE CUSTOMER AS WELL AS INFORMATION ABOUT POTENTIAL VULNERABILITIES OF THEIR EXPLOITATION. THE INFORMATION FROM THIS AUDIT REPORT CAN BE USED INTERNALLY BY THE CUSTOMER OR IT CAN BE DISCLOSED PUBLICLY AFTER ALL VULNERABILITIES ARE FIXED - THE DECISION OF THE CUSTOMER. Disclaimer: The smart contracts given for audit have been analyzed in accordance with the best industry practices at the date of this report, in relation to cybersecurity vulnerabilities and issues in smart contract source code, the details of which are disclosed in t his report, (Source Code); the Source Code compilation, deployment, and functionality (performing the intended functions). Because the total numbers of test cases are unlimited, the audit makes no statements or warranties on the security of the code. It also cannot be considered as a sufficient assessment regarding the utility and safety of the code, bugfree status, or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only we recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts. Smart contracts are deployed and executed on a blockchain platform. The platform, its programming language, and other software related to the smart contract can have their own vulnerabilities that can lead to hacks. Thus, the audit can’t guarantee explicit security of the audited smart contracts.
Consultant was contacted by MUSE dao (Customer) to conduct a Smart Contracts Code Review and Security Analysis. This report presents the findings of the security assessment of Customer`s smart contracts and its code review conducted between 05/03/2022 – 09/03/2022. The project has 1 file. It contains approximately 870 lines of Solidity code. All the functions and state variables are well commented on using the natspec documentation, but that does not create any vulnerability.
Token Name: Thoth
Token Symbol: Thoth
Platform: Ethereum
Audit Started Date: 05/03/2022
Audit Completed Date: 09/03/2022
Over and under flows
Short address attack
Visibility & Delegate call
Reentrancy / TheDAO hack
Forcing Ethereum to a contract
Timestamp Dependence
Gas Limit and Loops
DoS with (Unexpected) Throw
DoS with Block Gas Limit
Transaction-Ordering Dependence
Byte array vulnerabilities
Style guide violation
Transfer forwards all gas
ERC20 API violation
Malicious libraries
Compiler version not fixed
Unchecked external call - Unchecked math
Unsafe type inference
Here you are checking that balance of contract is bigger or equal to amount and transfer to recipient is successfully done or not.
Here you are checking that balance of contract is bigger or equal to value and target address is contract address or not.
Here you are checking that owner address is valid and proper or not.
Here you are checking that to address is not same as owner address, msg.sender is owner or not, or msg.sender has allowance for transfer.
Here you are checking that to address is valid and proper, and tokenId exists or not.
Here you are checking that token is available in from address or not, to address is valid and proper, or not.
Here you are checking that newOwner address is valid and proper or not.
Here you are checking that _add value is proper and valid address or not.
Here you are checking that tokenMinted value should be smaller than MAX_NFT_SUPPLY.
Here you are checking that mint is paused or not, tokenMinted should be smaller than MAX_NFT_SUPPLY.
Here you are checking that _cnt value is bigger than 0, mint is not paused, tokenMinted should be smaller than MAX_NFT_SUPPLY, sufficient eth is given, msg.sender is whitelisted for presale, and _cnt value is smaller than or equal to 5 for presale and _cnt value is 10 for public sale.
Here you are checking that sale and reveal is ongoing or not.
No Critical vulnerabilities found
No Medium vulnerabilities found
9.1. Compiler version is not fixed:
In this file you have put “pragma solidity ^0.8.0;” which is not a good way to define compiler version. Solidity source files indicate the versions of the compiler they can be compiled with. Pragma solidity ^0.8.0; // bad: compiles 0.8.0 and above pragma solidity 0.8.0; //good: compiles 0.8.0 only. If you put(>=) symbol then you are able to get compiler version 0.8.0 and above. But if you don’t use(^/>=) symbol then you are able to use only 0.8.0 version. And if there are some changes come in the compiler and you use the old version then some issues may come at deploy time.
9.2. Suggestions to add code validations:
You have implemented required validation in contract. There are some place where you can improve validation and security of your code. These are all just suggestion it is not bug.
No use of safeMath library
Function: _burn. Here in _burn method you can check that owner has sufficient balance or not.
Function: - setWhitelist. Here in your contract you are only able to make whitelisted to address but there is not a functionality which can remove address from whitelist. o So if you want to remove any address from whitelist in future then owner is not able to do it.
Function: - withdraw. here in withdraw method you can check that transfer to ownerAddress is successfully done or not.
Function: - setPrice. Here in setPrice methods you can check that priceextended value is bigger than 0.
Number of problems in the smart contract as per severity level:
High: 0
Medium: 0
Low: 6
According to the assessment, the smart contract code is well secured. The code is written with all validation and all security is implemented. Code is performing well and there is no way to steal funds from this contract. Good Point: Code performance and quality are good. Address validation and value validation is done properly.
Suggestions: Please try to use static solidity version, and try to implement suggested code validations.
No activity yet