ETH_aXpireToken_audit_report.md

aXpire (AXPR) Token audit report.

1. Summary

This document is a security audit report performed by danbogd, where aXpire (AXPR) Token has been reviewed.

2. In scope

• xxx.sol.

3. Findings

In total, 12 issues were reported including:

• 3 medium severity issues
• 1 low severity issues
• 6 owner privileges (ability of owner to manipulate contract, may be risky for investors)..
• 2 notes.

No critical security issues were found.

3.1. The owner can burn any value of tokens from of other token holders.

Severity: medium

Description

The owner or a hacker (if the owner's private key will be compromised) can burn any value of tokens he wants whithout any approve from token holders. This is dangerous for investors.

Code snippet

Lines 223-231.

3.2 Non-compliance with ERC-20 Token Standard.

Severity: medium

Description

ERC-20 Token Standard specifies for functions transfer and transferFrom:

The function SHOULD throw if the _from account balance does not have enough tokens to spend. But in this implementation it just returns false. This can lead to serious consequences. Because checking the return value of this function is rare.

EIP20 says that: Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event. But in this contract, functions transfer and transferFrom has a condition:

if (_value > 0)

Code snippet

Lines 155-176

3.3. Allowance Approval

Severity: medium

Description

Following ERC-20 final description:

"NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before"

The implemented approve function:

Do not preserve backwards compatibility since it enforces the allowance values to be set.

Do not throw in case if the following condition is true if (_value != 0 && allowed[msg.sender][_spender] != 0) and return false, users might not notice that the changes didn't occur, and external contract calls to this function will highlight many other issues.

Code snippet

Line 183.

Recommendation

Do not try to mitigate the issue and implement increaseApproval and decreaseApproval functions instead.

3.4. Known vulnerabilities of ERC-20 token

Severity: low

Description

1. It is possible to double withdrawal attack. More details here.

2. Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here.

Recommendation

Add into a function transfer(address _to, ... ) following code:

require( _to != address(this) );

3.5. Owner Privileges

Severity: owner previliges

Description

The contract owner allow himself to:

• pause functions of contract (transfer, transferFrom, approve);
• burn a specific amount of tokens of other token holders;
• change rate duaring crowdsale;
• stop croudsale;
• withdraw ETH and tokens funds before the end of sales;
• softcap is absent.

The contract is managed manually by the owner which is not good for investors.

3.6. Unused function.

Severity: note

Description

The function toggleDead() is not used.

Code snippet

Line 340.

3.7. Consider using latest version of solidity.

Severity: note

Description

The contracts use solidity version 0.4.24. It is suggested to use the latest version and fix all compiler warnings that arise. Compiler version should be fixed to avoid any potential discrepancies in smart contract behavior caused by different versions of compiler.

4. Conclusion

The review did not show any critical issues, some of medium and low severity issues were found.