FansUnite Audit

The ZK Labs auditors were hired by the FansUnite team to conduct 2 separate audits of their crowdsale and token contracts, which can be found in the FansUnite github repository. The team audited the smart contract versions found in the commit 1c989dbd269958df1d474d5e29ed11e96e7efee0.

The severe issue mentioned below were fixed by the FansUnite team as of the commit 75cc4b3d1a6232bdd107b17637bb264a94981e04.

Full report by Dean Eigenmann.

Along with investigating some of the security issues, we added some of our recommendations that could be implemented to simplify and improve the code.

Severe

A severe issue was found which would lead to the failure of finalization of the crowdsale. This was due to the fact that the last purchase could exceed token cap, causing an exception to be thrown by SafeMath in the finalize method.

This issue could occur not only through the purchase function, but also through the addPrecommitment function, which allows the FansUnite team to allocate tokens to addresses.

The solution of this issue was to simply check that an allocation through either the addPrecommitment or the purchase function does not exceed the maximum limit.

Suggestions

Along with the issue we had found, we also found a series of improvements and changes that could be made to the code.

• The MinGoalReached event can be removed as it is never used.
• The multiplier 10**24 is used repeatedly, a constant could be created in place.
• The doPurchase function is passed a parameter called _owner that is unused. We suggested to remove this parameter and simply use the msg.sender constant.
• We suggested that the transfer method call in the doPurchase function should use the weiAmount variable rather than the msg.value constant.
• We suggested that the addToWhitelist function should be adapted so an array of addresses could be whitelisted. This would reduce the amount of transactions required significantly.
• We suggested to the developers that the FansUniteToken could be easily replaced with contracts from the OpenZeppelin library.
• The TokenVesting contract constructor could be modified to automatically multiple the _duration variable by 1 weeks, simplifying what needs to be passed.
• It could occur that the finalize method mints 0 tokens to the unsoldSupplyAddress, we suggested that a check should be added.

Conclusion

We found one severe issue, which we explained to the FansUnite team along with a list of possible methods to fix the issue. Additionally we proposed changes to follow best practice standards as well as increase the legibility of the code.