TravelHelper smart contract audit report .

We’ve been asked by the TravelHelper ( team to review and audit their new token code. Here is their unaudited token contract code. We looked at their contract and now publishing our results.


High vulnerability issues:

Unmet condition in burnTokensForSale():-

There is a requirement (tokens > 0) statement in the burnTokensForSale() function, where tokens are the balance of crowdsale contract so it means that this function can only succeed when all tokens will be sold. In crowdsale function there is a function finalizeAndBurn() which burns the tokens first and then finalize the sale, finalizing the sale means that investors can transfer their tokens after finalizing the sale. So the bug here is that if all tokens will be sold than this function will never succeed as it will be revert in burnTokensForSale() and investors will never able to transfer their tokens.

Medium severity issues:

There was no medium severity issue found.

Low severity issues:

Solidity version should be fixed in smart contracts. For example- It should be
pragma solidity 0.4.24 and not pragma solidity ^0.4.24
Transfer Events are not emitted in activateSaleContract() function in token contract.
Final comments:-
The contract should be properly commented. It is not commented in some places. It is advised to comment the code as it is good practice.
2. Use of block number instead of timestamp is done perfectly.

You can check the unaudited and audited code along with the report in the following github repo.(

All the changes suggested by our team has been applied by TravelHelper. So their contracts are secure now as of our investigation and their audited contracts are already deployed on the main net.

We’re available for smart contract development and security auditing work. You can fill this form to get in touch.