aXpire Security Audit Report
Here is the report of the aXpire Security Audit performed by the Callisto Network security department in May 2019.
About Callisto Network and the security department
Utilizing Callisto Network capabilities, we have established a free-for-all system of smart-contracts auditing, to this end, Callisto Network has founded the Callisto security department and deploys treasury funds to pay security auditors for auditing smart-contracts, to reduce risk/flaw in smart-contracts and improve the adoption of programmable blockchains for the whole crypto industry.
aXpire Security Audit Report
aXpire smart contract security audit report performed by Callisto Security Audit Department.
2. In scope
In total, 10 issues were reported including:
- 1 medium severity issues.
- 4 low severity issues.
- 5 owner privileges (the ability of an owner to manipulate contract, may be risky for investors).
3.1. ERC-20 Compliance
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
valueis equal to 0 the functions do not fire a Transfer event and return false.
transfer“SHOULD” throw when the
msg.senderdoesn’t have enough fund.
- Same as previously following the specifications
transferFromshould throw and not return false if the
_fromaddress doesn’t have enough of fund or if the allowed value isn’t enough to cover the transaction
3.2. Owner Privileges
Severity: owner privileges
Contract owner allows 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.
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.3. Allowance Approval
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 partially solves double withdrawal attack but create incompatibility for some Dapps, and do not allow the user to directly reduce the allowance creating a race between user and spender.
3.4. Transfer Event
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 is related to both constructor and
createTokens function since tokens are created and transfer event is not triggered.
3.5. Transfer to address(0)
transferFrom transfers to
address(0) are allowed.
3.6. Known vulnerabilities of ERC-20 token
- It is possible to double withdrawal attack. More details here.
- 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.
Add the following code to the
transfer(_to address, ...) function:
require( _to != address(this) );
The audited smart contract has issues with ERC20 Compliance and cannot be used as ERC20 token. Reported issues must be fixed prior to the usage of this contract.