Unuslabs - Audit

In the contract `TokenVesting` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add beneficiaries to the private round of investors, release vested tokens, and withdraw tokens from the contract. 

Tokens are sent to owner when deploying the contract. This could be a centralization risk as the owner can distribute tokens without obtaining the consensus of the community.

The linked comment statement contains a typo in its body, namely `tockens`.

The following function is declared as `public`. Functions that are never called internally within the contract should have `external` visibility.

Pragma should be locked to specific compiler version and flags that they have been tested the most with. Locking the pragma helps ensure that contracts do not accidentally get deployed using, for example, the latest compiler, which may have higher risks of undiscovered bugs.

State variables that never change should be declared as `constant` to save gas. ```solidity=41 uint256 private slicePeriodSeconds = MONTH; ``` - `slicePeriodSeconds` should be declared `constant`.

Literals with many digits are difficult to read and review.

The return value of the transfer()/transferFrom() call is not checked. ```solidity=263 token.transfer(_msgSender(), balance); ```

`block.timestamp` is used for comparison, which can be risky since timestamp can be influenced by miners. That means the miner creating the block can manipulate the `block.timestamp`, to some degree, and change the outcome of the transaction. ```solidity=116 vestingStartTS = block.timestamp; ``` --- ```solidity=147 privateRoundInvestors[_beneficiary] = PrivateRoundInvestor( _amount, 0, block.timestamp ); ``` --- ```solidity=212 uint256 currentTime = block.timestamp; ``` --- ```solidity=237 uint256 currentTime = block.timestamp; ``` --- ```solidity=270 uint256 currenttime = block.timestamp; ```

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring Ether, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=256 to.transfer(amount); ``` - `TokenVesting.withdrawEth` uses `transfer()`.