ryu9827 / Mothership-contracts

Mothership Token Sale Audit Report

Preamble

This audit report was undertaken by BlockchainLabs.nz for the purpose of providing feedback to Mothership. It has subsequently been shared publicly without any express or implied warranty.

Solidity contracts were sourced from the public Github repo mothershipcx/contracts prior to commit 8870a507f3fa052519a8bb8275ccd4704d6b964b - we would encourage all community members and token holders to make their own assessment of the contracts.

Scope

All Solidity code contained in /contracts was considered in scope along with the tests contained in /tests as a basis for static and dynamic analysis.

Focus Areas

The audit report is focused on the following key areas - though this is not an exhaustive list.

Correctness

• No correctness defects uncovered during static analysis?
• No implemented contract violations uncovered during execution?
• No other generic incorrect behaviour detected during execution?
• Adherence to adopted standards such as ERC20?

Testability

• Test coverage across all functions and events?
• Test cases for both expected behaviour and failure modes?
• Settings for easy testing of a range of parameters?
• No reliance on nested callback functions or console logs?
• Avoidance of test scenarios calling other test scenarios?

Security

• No presence of known security weaknesses?
• No funds at risk of malicious attempts to withdraw/transfer?
• No funds at risk of control fraud?
• Prevention of Integer Overflow or Underflow?

Best Practice

• Explicit labeling for the visibility of functions and state variables?
• Proper management of gas limits and nested execution?
• Latest version of the Solidity compiler?

Focus Areas

The audit report is focused on the following key areas - though this is not an exhaustive list.

Correctness

• No correctness defects uncovered during static analysis?
• No implemented contract violations uncovered during execution?
• No other generic incorrect behaviour detected during execution?
• Adherence to adopted standards such as ERC20?

Testability

• Test coverage across all functions and events?
• Test cases for both expected behaviour and failure modes?
• Settings for easy testing of a range of parameters?
• No reliance on nested callback functions or console logs?
• Avoidance of test scenarios calling other test scenarios?

Security

• No presence of known security weaknesses?
• No funds at risk of malicious attempts to withdraw/transfer?
• No funds at risk of control fraud?
• Prevention of Integer Overflow or Underflow?

Best Practice

• Explicit labeling for the visibility of functions and state variables?
• Proper management of gas limits and nested execution?
• Latest version of the Solidity compiler?

Classification

Defect Severity

• Minor - A defect that does not have a material impact on the contract execution and is likely to be subjective.
• Moderate - A defect that could impact the desired outcome of the contract execution in a specific scenario.
• Major - A defect that impacts the desired outcome of the contract execution or introduces a weakness that may be exploited.
• Critical - A defect that presents a significant security vulnerability or failure of the contract across a range of scenarios.

Findings

Minor

• Expected ' { ' after for and if statement - Best practice# MultiSigWallet.sol #L140 & etc.View on GitHub
  • Not Fixed
• Using obsolete keyword constant - Best practice# Contribution.sol #L256 & etc.View on GitHub
  • Not Fixed
• Recommend using pure instead of constant on safe math library - Best practice# SafeMath.sol #L32 & etc.View on GitHub
  • Not Fixed
• Recommend using the latest version(0.4.13) of Solidity supported by Truffle.js - Best practiceView on GitHub
  • Not Fixed
• Version number is not align with other contracts - Best practice Migrations.sol L1 View on GitHub
  • Not Fixed
• Explicit declaration of function access modifier – best practice of ERC20Token standard - Best practice MultiSigWallet.sol L92 View on GitHub
  • Not Fixed
• Throw is deprecated, in favour of revert, require and assert - Best practice MultiSigWallet.sol L36 View on GitHub
  • Not Fixed
• getBlockNumber() been duplicated defined in 3 different contracts. Consider abstract to a super contract for easier inheritance - Best practice SITExchanger.sol L90, MiniMeToken.solL489, Contribution.solL326 View on GitHub
  • Not Fixed
• Magic numbers used - Best practice Contribution.sol L285 , ContributionWallet.sol L51View on GitHub
  • Not Fixed

Moderate

• None found

Major

• None found

Critical

• None found

Conclusion

Overall we have been fully satisfied with the resulting contracts following the audit feedback period. We took part in carefully reviewing all source code provided, including deployment testing.

We are pleased to report that no potential vulnerabilities were uncovered during the audit. That the token complies with the recently finalised ERC20 Token Standards. The code has excellent testability and the developers have followed common best practices.

Of the issues we have raised all of them are minor. This crowdsale has a low risk of ethereum being hacked or stolen.