Stasis Token Smart Contract Audit

Coinfabrik has been hired to audit the smart contracts for Stasis sale, the Stable Euro Token.   

Firstly, we wrote a brief summary with our discoveries. After that, we addressed the detailed findings and what are the enhancements we propose to improve the code. And at the end, we wrote the conclusion with the most important issues to correct if there were any, and how we considered the code after being analyzed by our team.

Summary

The contracts audited are from the STASIS-EURS-token-smart-contract repository at https://github.com/STASISNET/STASIS-EURS-token-smart-contract. The audit is based on the commit 383eedb3e5002ed244b15fb2fba1cfa147a6da67. The audited contracts are SETToken.sol, which handles the token sale, SafeMath.sol, which a code library for performing overflow-free arithmetic operations not unlike the ones commonly used, and AbstractToken.sol, which is a generic token contract from which methods are inherited.

The following analyses were performed:

• Misuse of the different call methods: call.value(), send() and transfer().
• Integer rounding errors, overflow, underflow and related usage of SafeMath functions.
• Old compiler version pragmas.
• Race conditions such as reentrancy attacks or front running.
• Misuse of block timestamps, assuming anything other than them being strictly increasing.
• Contract softlocking attacks (DoS).
• Potential gas cost of functions being over the gas limit.
• Missing function qualifiers and their misuse.
• Fallback functions with a higher gas cost than the one that a transfer or send call allows.
• Fraudulent or erroneous code.
• Code and contract interaction complexity.
• Wrong or missing error handling.
• Overuse of transfers in a single transaction instead of using withdrawal patterns.
• Insufficient analysis of the function input requirements.

Detailed findings

Minor severity

Inconsistent use of SafeMath library

In delegatedTransfer the following operation takes place, which could cause an overflow:

  nonces [_from] = _nonce + 1;

We strongly suggest the use of SafeMath, or the use of the library supplies in the repository. By forcing the use of such code libraries the code is guaranteed to avoid situations like overflow.

Enhancements

Use of latest compiler pragmas

The contracts provided use the following compiler pragmas:

pragma solidity ^0.4.20;

We strongly suggest updating the compiler version, so as to avoid any possible legibility issues, since newer compiler versions include features such as distinguishing the constructor and event emission with keywords, which means the legibility of the contract is improved against possible future developments.

Conclusion

We found that the smart contracts audited were simple and straightforward and we were given an adequate amount of documentation. The delegatable modifier was especially considered, and was found to be acceptable. Test coverage was found to be appropriate and well done. Functions like delegatedTransfer and TransferFrom were specially audited, and we consider that they were both safe.