UTRUST Smart Contract Audit

Given all the attention ICOs are getting right now, and the vast potential for losses if security mistakes are made, it’s hardly surprising that new launches continue to fall victim. But the team here at Positive.com are really encouraged to see some organizations are taking a more serious approach to security well before they go live.

Take the guys at UTRUST, for example. In advance of their 2nd November launch date, UTRUST asked our security consultants to simulate a real-world attack on their system. The aim was to identify any weaknesses, and provide reassurance to their potential investors on the quality of the UTRUST platform.

Our team performed detailed analysis of the UTRUST smart contract, a vulnerability assessment of the company’s resources and conducted open-source intelligence gathering. The smart contract proved to be of excellent quality. Our team found no vulnerabilities and recommendations were limited to a few points of best-practice.

Overall, UTRUST’s exposure is very limited and no critical issues were identified. We did find credentials from some UTRUST members on lists of previously-leaked passwords. In some cases, these accounts were still in use, but were not verified as being directly associated with UTRUST assets.

This is great news for UTRUST’s investors, but also signals that this burgeoning industry is getting serious about the crucial role of pre-launch security assessments. And not a moment too soon!

The detailed lowdown on UTRUST

So here, what we found. The audited contract is in the utrustdev/smartcontract private repository. The version analyzed by our team is the commit c23f73a6188fea361223b0535063aa4ab6ce4960.

No vulnerabilities were found since the contract is built on top of OpenZeppelin’s StandardToken implementation without any own additional code.

Our team made only two minor recommendations:

1. Raising the minimum version of Solidity compiler to the latest version.

2. Incorporating a newer OpenZeppelin commit that adds precondition checks for available balance in ‘transfer’ and ‘transferFrom’ functions. This is not a security issue since ‘SafeMath’ will still throw if the requested value is bigger than the available balance, but it will assure better readability and understanding of the smart contract business logic.

Disclaimer: This report reflects our findings during a security assessment carried out on the UTRUST smart contract and selected information security resources in October 2017. It is not a guarantee of security levels after that date. We have not made a security assessment of the full UTRUST project. The findings of this report should not be considered as investment advice. For more information on smart contract security, visit our website.