IBStoken - Audit

In the contract `Pausable` 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 pause/unpause token transfers. 

All of the IBSTokens are sent to the contract owner which is an externally-owned account (EOA) address on deployment. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The blacklist feature is designed to prevent the blacklisted users from transferring the `IBSToken` to others by validating the following **require** statement: ```solidity=145 function transferFrom(address _from, address _to, uint256 _value) public returns (bool) { require(tokenBlacklist[msg.sender] == false); ``` The **require** statement prohibits the blacklisted users from calling `transfer()` and `transferFrom()` to move their funds by requiring the `msg.sender` not blacklisted. However, this feature can be bypassed by using a combination of the `approve()`/`increaseAllowance()` and `transferFrom()` functions. The blacklisted user could approve another account to transfer his tokens on his behalf.

The data type of the decimals state variable should be `uint8` to adhere to the EIP-20 standard. Currently, some smart contracts interacting with this ERC-20 token will result in a failure. Reference: [Specification of the `decimals()` Method](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md#decimals)

The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.