The Sharp Token(TT10)

The ability of the contract owner to regulate the use of the token with the use of the Pausable library shows the centralization power centered on the contract owner. The owner of the contract can pause the contract and users will no longer be able to use these tokens again unless the owner unpauses the contract. When the contract is paused, the “beforeTransfer()” created in the Pausable returns the state of _paused variable. This is called in the following functions:• transfer • transferFrom • decreaseAllowance Also, with the presence of the TransferOwnership function in the token contract, it shows that the contract owner can transfer not just the ownership of the contract, but transfer the tokens present in the former contract address to the new contract address.

the beforeTransfer() function is a view function that returns a boolean and this is called in the require check of some critical function. The issue arises with comparing the returned value to the “false” constant.

according to the contract, the beforeTransfer function is used to pause critical functionalities such as transfer, transferFrom, and decreaseAllowance. However, this was not included in some other critical functions, like for instance, the direct opposite to the decreaseAllowance function, increaseAllowance, do not have the beforeTransfer check. This implies that when the contract is paused, users can still increase allowances of the approved addresses but they cannot decrease the allowances. Also another function is the approved function, this poses that token holders can still approve tokens to addresses. There is no essence of approving tokens that cannot be transferred.

Contracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.

The codebase has comments on each of the functions. However, it fails to prototype the Natspec code comment format that details the functions more appropriately. With the use of the Natspec format, it is easier to cite the expected function inputs and explain them. This makes for easy comprehension of the codebase and is often recommended as the conventional way to comment solidity smart contracts.