ETH_aXpire_report.md

aXpire Audit Report.

1. Summary

This document is a security audit report performed by RideSolo, where aXpire Token has been reviewed.

Symbol      : AXPR
Name        : aXpire
Total supply: 350,000,000
Decimals    : 18 
Standard    : ERC20

2. In scope

• aXpire Token .

3. Findings

7 issues were reported:

• 1 high severity issues.
• 2 medium severity issues.
• 4 low severity issues.

3.1. ERC-20 Compliance

Severity: medium

Description

Following EIP-20 specifications:

• Transfers of 0 values "MUST" be treated as normal transfers and fire the Transfer event, this issues is applicable for both transfer and transferFrom since if value is equal to 0 the functions do not fire a Transfer event and return false.
• transfer "SHOULD" throw when the msg.sender doesn't have enough fund.
• Same as previously following the specifications transferFrom should throw and not return false if the _from address doesn't have enough of fund or if the allowed value isn't enough to cover the transaction _value.

Code snippet

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L155

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L166

3.2. Token Cap

Severity: medium

Description

tokenCreationCap is set be 350M tokens, in the contructor tokenCreationCap is totaly assigned to escrowFundDeposit, meaning that no more token creation can be done. However in the sale functin createTokens investors can by tokens using ether, all bought tokens are added to the totalSupply that already include tokenCreationCap that was already given to escrowFundDeposit. The total supply checking is done using checkedSupply that is the addition of the totalSupply and the tokens bought tokens as commented check that we're not over totals, but there is not limit in totalSupply creation since the values are just added.

Please note that the following condition will never throw, tokenCreationCap will be always lower than checkedSupply:

      if (tokenCreationCap < checkedSupply) 
        revert();  // odd fractions won't be found

Code snippet

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L263

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L293

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L310

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L316

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L317

3.3. Owner Priviliges

Severity: High

Description

Contract owner allow himself to:

• Burn from any address, making all users at a critical severity risk, such behavior cannot be accepted by the investors. Once tokens are allocated to and address it belongs only to that address to burn the tokens, check here.
• pause/unpause approval/transfer/transferFrom, check here.
• halt/unhalt token sale, check here.
• Ico can be ended by owner only, check here.
• Reset the sale exchange rate at any moment, check here.

3.4. Allowance Approval

Severity: low

Description

Following ERC20 standard, approve function "Allows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.", However the implemented function throw in case if allowed[msg.sender][_spender] is different than zero and _value different than zero. this partialy solve double withdrawal attack but create incompatibility for some Dapps, and do not allow the user to directly reduce the allowance creating a race betweenn user and spender.

Code snippet

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L183

3.5. Transfer Event

Severity: low

Description

Following EIP-20 when "A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created".

This issue issue is related with both constructor and createTokens function since tokens are created and transfer event is not triggered.

Code snippet

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L277

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L317

3.6. Transfer to address(0)

Severity: low

Description

In both transfer and transferFrom transfers to address(0) are allowed.

Code snippet

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L155

https://gist.github.com/RideSolo/65ca7446379c3d261ca9d2d2e1c7508a#file-axpire-sol-L166

3.7. 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 the following code to the transfer(_to address, ...) function:

require( _to != address(this) );

Conclusion

Token and ICO are implemented on the blockchain to decentralize and limit human intervention and possible hacks, The implemented token is completely centralized around the owner. Investos are not safe.