StandardToken Manual Review Findings

STN-01M: Inconsistent Restrictions

Description:

The increaseApproval and decreaseApproval functions permit the allowance of the zero-address to be set whereas the approve function allow does not permit it to be done so.

Example:

Copy
27function approve(address _spender, uint256 _value) public returns (bool) {
28  
29  require(_spender != address(0),"invalid address");
30  allowed[msg.sender][_spender] = _value;
31  emit Approval(msg.sender, _spender, _value);
32  return true;
33}
34
35
36function allowance(address _owner, address _spender) public view returns (uint256) {
37  return allowed[_owner][_spender];
38}
39
40function increaseApproval(address _spender, uint _addedValue) public returns (bool) {
41  allowed[msg.sender][_spender] = allowed[msg.sender][_spender].add(_addedValue);
42  emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
43  return true;
44}

Recommendation:

We advise the restrictions to become consistent across the codebase by introducing this check in the increase and decrease prefixed functions as well.

Alleviation:

A require check was introduced to both functions disallowing an allowance to be adjusted for the zero-address.

STN-02M: Incorrect Approval Mechanism

Description:

The approve function sets a _value that is meant to be transferred from an account by a particular user. However, this _value is denoted as a literal and is not "normalized" using the demandFactor which can lead greater or lower values than intended to be transacted if the demandFactor changes.

Example:

Copy
27function approve(address _spender, uint256 _value) public returns (bool) {
28  
29  require(_spender != address(0),"invalid address");
30  allowed[msg.sender][_spender] = _value;
31  emit Approval(msg.sender, _spender, _value);
32  return true;
33}

Recommendation:

We advise the allowed mapping to contain normalized values that allowance and the transferFrom invocations properly utilize.

Alleviation:

The value stored within the allowed mapping now properly takes into account the demandFactor of the token.

STN-03M: Redundant & Inaccurate Evaluations

Description:

The require check for the balanceOf measurement is susceptible to the same inaccuracies as the one performed in BasicToken and is done so for the balanceOf of the msg.sender instead of the _from address. The evaluation of the allowed value is redundant given that a SafeMath invocation is performed on the allowed mapping in its subtraction.

Example:

Copy
12require(_to != address(0),"invalid address");
13require(_value <= balanceOf(msg.sender),"value exceed user balance");
14require(_value <= allowed[_from][msg.sender],"value exceed allowed by user");
15require(transferAllowance,"Not allowed to transfer");
16
17uint256 _value1 = (_value.mul(1 ether)).div(demandFactor);
18balances[_from] = balances[_from].sub(_value1);
19balances[_to] = balances[_to].add(_value1);
20allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value);

Recommendation:

We advise both require checks to be safely omitted from the codebase. If error messages are desired to be manually specified, a wrapper of the SafeMath implementation can be used whereby the message is passed along with the invocation of a function allowing custom messages to be emitted.

Alleviation:

The require checks that were using the incorrect balances were entirely omitted from the codebase thus alleviating this exhibit.