This story was shared from this site

This post presents the results of Matryx token sale and token smart contract audit. TokenMarket smart contract development team ensured that the smart contract development follows the community best practices, conforms to the advertised sale parameters, gives purchaser protection expected by the community and conforms to Ethereum token standards.

This is not a purchase advise; this is a technical report stating that token and token sale function as advertised.

About Matryx

Matryx is a platform for decentralized collaboration. Matryx consists of a bounty system, a library of digital assets, and a marketplace. Problems are posted, along with a bounty for a verified solution. Users then collaborate to solve problems, share results, and earn rewards. Rewards are given to all contributors, and all submissions are added to the Matryx library and marketplace for future purchase. This will create an ecosystem of public collaboration and ideas that will drive research and innovation.

View Matryx on TokenMarket.

Matryx presale starts 6th September. Matryx token sale starts 13th September.


The following aspects of the smart contracts were considered

  • General software development best practices

  • Code quality

  • Automated test suite

  • Logic sanity check

  • Solidity safety checklist

  • Conform to advertised token sale parameters

  • ERC-20 standard and best practices

  • Purchaser protection

  • EtherScan code verification

General software development best practices

All ok.

The code was provided to the auditors on Github. The codebase was properly version controlled.

The audited code is the commit

The codebase is heavily inspired by TokenMarket ICO smart contract library. The codebase further uses community managed high quality Truffle and Open Zeppelin frameworks. These software development practices and components match the expected community standards.

Code quality

All ok – only cosmetic remarks.

The codebase was thoroughly commented out and follows Solidity naming conventions and such development community best practices. Solidity standard for semantic function commenting – NatSpec – was occasionally used, we’d encourage using the standard for every function.

Revert() will be implemented in the future Ethereum Metropolis version, and is encouraged in newly written code. In the newly written code one should use revert() instead of throw. There were still some old throw statements in the codebase.

Require() is well and widely used: Good practice is to use require in the beginning of a function, exactly how it’s used in the code. Assert() should be used in regular checks during the function execution, however, assert() is not used in the code.

Automated test suite

All ok.

The automated test suite covers the critical functionality of the token and the parameters of the token sale. The automated test suite stressed the exact same contract code as is deployed to production.

Logic sanity check

The token sale follows the advertised presale and sale mechanism. The token sale correctly finalizes itself. Tokens are distributed as advertised and the token becomes transferable at the end of the sale. Presale and retail sale caps are properly checked.

Solidity safety checklist

All ok – only cosmetic remarks.

The Solidity safety checklist of wiki was used the as the guideline for Solidity safety checks. This checklist provides community gathered wisdom for preventing potential attack vectors and pitfalls in smart contract programming.

The code is written for Solidity version 0.4.13 which is known to have two bugs with “delegatecall” and “ecrecover” (“low” and “medium” severity respectively). Since neither is used in the code, 0.4.13 is considered as a safe version to use.

Public visibility modifier was not always specified. After the Parity multisig incident, defining a visibility modifier for every function is recommended.

SafeMath library was used in every arithmetic operation where variables were used, which is essential to prevent integer overflows.

Since the Crowdsale does not implement refunding, no foreign (non-trusted) addresses are called, and even for the trusted multisig wallet address transfer() is used, which is the preferred way. The trusted multisig wallet is based on well known and widely used Gnosis codebase. Since the code does not interact with non-trusted addresses, we don’t expect problems with re-entrancy attacks, call-stack attacks, DoS with unexpected throw, or malicious libraries.

The code does not use loops, so gas manipulation using loops is not possible.

Token pricing uses integer division. The team have been noted about the rounding behavior, so that this is clearly expressed when communicating prices in the marketing material.

Only buy() and buyTokens() accepts ethers, so forced balance updates are not expected.

Because of the nature of the code, Transaction-Ordering Dependence is not relevant.

Conform to advertised token sale parameters

All ok.

The crowdsale parameters match of those given by the Matryx team members. At the writing of this, there was no definite terms of sale or whitepaper where to confirm these numbers, so the numbers were directly communicated with the team.

  • Start time: 3:00:00 pm UTC Wednesday, September 13

  • End time: 3:00:00 pm UTC Friday, October 13

  • Presale start time: 3:00:00 pm UTC Wednesday, September 6

  • Presale end time: 3:00:00 pm UTC Wednesday, September 13

  • Presale tiers

    • Min: 75 ETH, base rate: 1165 tokens per ETH, 0.000858392 ETH per token

    • Min 150 ETH, 10% discout rate: 1294 tokens per ETH, 0.0007725528 ETH per token

    • Min 300 ETH 15% discount rate: 1371 tokens per ETH, 0.0007296332 ETH per token

    • Whitelist 20% discount rate: 1456 tokens per ETH 0.0006867136 ETH per token

  • Presale cap: 80901.5 ETH

  • Retail sale cap: 161,803 ETH

  • Total supply: 314,159,265 MTX

  • The company will retain all unsold tokens

ERC-20 standard and best practices

All ok.

OpenZeppelin’s and TokenMarket’s token contracts were used and inherited correctly. The race condition is taken care of, and mitigated correctly. The short-address-attack is not taken into account, but we don’t encourage that, since it can be considered as bad practice.

MatryxToken is using 18 decimals, which is considered to be the contemporary prelevant best practice for ERC-20 tokens, and will be used by future ERC-233 tokens. Using same amount of decimals across token contracts will help to mitigate integration problems in the future.

UpgradeableToken token upgrading mechanism is implemented. This mechanism was first described in Gnosis whitepaper.

Purchaser protection

All ok.

There is no minimum funding goal. Thus, all purchases can be considered final.

Purchasing tokens require Ethereum data field transaction to be filled in. Furthermore the gas limit requirement is high. This ensures that contributions are not sent from cryptocurrency exchange where the delivery of tokens might fail.

The token is transferable when the token sale ends as the owner finalizes the token sale.

In the case there is need for refunds, they can be organized manually.

EtherScan code verification code verification mechanism ensures that the compiled source code matches the deployed smart contract bytecode in the blockchain. EtherScan acts as a service to easily check repeatable builds of smart contracts.

The EtherScan proof of compile correctness is here.

About the authors


Leave a Reply

Your email address will not be published. Required fields are marked *