This is an audit of savedroids’ smart contracts for their SVD token presale.

The audited contracts can be found here:

The reviewed version was commit 4f3c014 on Bitbucket.

Overview

The process for the token presale is explained in savedroid’s whitepaper. Only whitelisted participants can buy SVD token in exchange for fiat, BTC or ETH. If all conditions are met, the investment will be transferred to a predefined wallet. The minimal purchase amount is 10 SVD, the maximum amount 100,000 SVD, while the price for 1 SVD token is set to 1.00 Euro. During the presale, a total of 5% of the maximum number of SVD token available for purchase (60,000,000.00) will be sold. Each participant will receive a bonus of 30% on the number of tokens purchased during the presale. The presale bonus as well as the referral bonus will be asssigned via functionalities outside of the smart contracts. This is why there are no sale caps defined. Contributed investments will be directly forwarded to a wallet that is setup and managed by savedroid’s escrow.

Critical issues

No severe security issues were found.

Moderate issues

No moderate security issues were found.

Minor issues

Consider changing the comparison operator in line 122 (SvdPreSale.sol) from > to >= , as the presale will be already started when startTime is reached.

, as the presale will be already started when startTime is reached. It is recommended to fix the pragma version in line 1 (SvdPreSale.sol) by removing the ^ caret , as there could be major changes between versions. — Fixed in commit 77fb969.

, as there could be major changes between versions. — Fixed in commit 77fb969. The investment forwarded is not an ETH amount, but a wei amount. Consider changing the name from eth to wei in the comment in line 144 (SvdPreSale.sol). — Fixed in commit 77fb969.

in the comment in line 144 (SvdPreSale.sol). — Fixed in commit 77fb969. There could be a potential problem using now in line 122, 130 and 156 (SvdPreSale.sol), which is an alias for block.timestamp, because miners can manipulate the timestamp. Therefore, it is generally recommended to use block.number instead, and approximate dates with expected block heights and time periods with expected block amounts. However, the probability is very low and the potential impact is limited.

Notes & additional information

The Solidity compiler version used in the contracts is 0.4.18. This is not the latest version (0.4.19), however there are not relevant bug fixes affecting this code so it is considered safe to use.

The EtherScan.io code verification mechanism ensures that the compiled source code matches the deployed smart contract bytecode to the blockchain. The proof of correctly compiled contracts on the Rinkeby testnet can be found here: FxRates and SvdPreSale.

Security practices used

SafeMath is used for Integer numbers in order to prevent overflows.

No loops are used in the contracts, which avoids gas manipulations using loops.

Visibility modifiers are always used.

The contracts do not interact with foreign (non-trusted) addresses, so problems with re-entrancy attacks, call-stack attacks or DoS with unexpected throw are not expected.

tx.origin is not used in the contracts.

As formal smart contract security audits are exhaustive enough to be safe, the implementation of a bug county is recommended. At the time of this audit, the savedroid team told they are already setting up a bounty campaign.

The tests cover the critical functionalities and parameters of the presale contract. They can be found here: FxRates and SvdPreSale.

Code quality

Function and event names are differentiated properly to prevent the risk of confusion.

Variables and functions are named in a descriptive manner.

Visibility of variables and functions are marked properly and consistently.

Conclusion

The smart contracts are very well written. The code is clean, easy to read and well commented with explanations. It follows common contract security patterns and good practices according to the Open zeppelin framework. There is a good amount of checks for verifications in place. No critical or severe issues were found. Some minor changes were suggested to follow best practices and reduce potential risks.

Update I (18th of January, 2018):

After the presale of savedroid ended, the SVD tokens will now be released via a minting smart contract. This update reviews this SvdToken.sol contract (commit d42f0c9 on Bitbucket).

The functionality of the contract only allows for minting of tokens directly to specific addresses, instead of assigning all tokens to the contract owner first.

The SvdToken contract strongly follows best practices of the Open zeppelin framework by inheriting functionalities and calling super-functions.

Minor issues

As the MintableToken#mint function works for zero amounts, a manual check should be implemented in order to not allow for addresses with zero tokens to be minted.

Commenting: Line 11: Content in the comment missing (Line 11) and Typo (Line 13, should be burning).

Update II (5th of February 2018):

The main sale of SVD tokens during savedroid’s ICO period starts on the 9th of February 2018. In regard to this, the main sale contract SvdMainSale.sol is reviewed (commit 4d1c9ff on Bitbucket).

Generally speaking, best practices according to the Open zeppelin framework and their standard contracts are being used.

It is to be noted, that contrary to the standard Crowdsale.sol contract, minting of the SVD tokens is not done on the fly in this case. Rather, the contract aims to collect investments in Wei, forwards it to the savedroid wallet and logs the investments for token assignment later on.

Minor issues

The comments in line 79 and 87 refer to the adaption of Crowdsale#hasEnded of the Open zeppelin Crowdsale.sol standard contracts. The comments can be ommitted.

Good practice sources

Author

Sebastian Hoffmann — Smart Contract Auditor @ digiseven & Owner @ tokenstartup for savedroid

Disclaimer

This smart contract audit is not a legally binding document and does not guarantee discovery of all potential vulnerabilities. It is recommended to perform several independent audits and public bug bounty program to ensure the security of the smart contracts.