ETH_idex_audit_report.md

idex audit report.

1. Summary

This document is a security audit report performed by danbogd, where idex has been reviewed.

2. In scope

Сommit hash 4a05eb28e570e9820066474ff2adc924ce7a27bd.

• DVIP.sol.
• Exchange.sol.
• ExchangeWhitelist.sol.
• MyToken.sol.

3. Findings

In total, 5 issues were reported including:

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

Critical security issue was found.

3.1. Missing return value bug

Severity: high/critical

Description

ERC-20 Token Standard specifies for function transfer. The current convention is for ERC20 tokens to revert if there's an error and return true if there isn't, because this is safest should work for everyone. But in this implementation transfer function returns 0 bytes is violating the ERC20 interface.

The biggest risk is that a smart contract that is compiled with solc ≥ 0.4.22 , which is expecting an ERC20 interface, will not be able to interact with MyTokens. This could mean that tokens which are send to such a contract, will be stuck there forever even if the contract has a function to transfer ERC20 token. There are many different scenarios where contracts, handling ERC20 tokens would run into this bug. One example is, that you would not be able to use decentralized exchanges that compiled its contract with solc ≥ 0.4.22 with this implementation of MyToken. More details here.

Code snippet

https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/MyToken.sol#L34

3.2. 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.3. ERC20 Compliance.

Severity: low

Description

Accroding to ERC20 standard, when initializing a token contract if any token value is set to any given address a transfer event should be emited.

Code snippet

https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/MyToken.sol#L26

3.4. Check for an empty input value.

Severity: low

Description

There is no check for an empty input value.

Code snippet

https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/Exchange.sol#L42 https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/Exchange.sol#L49 https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/Exchange.sol#L53 https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/ExchangeWhitelist.sol#L33 https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/ExchangeWhitelist.sol#L40 https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/ExchangeWhitelist.sol#L44

3.5. Deprecated method.

Severity: note

Description

The function () { throw; } was a pattern used to prevent implicit acceptance of ether in Solidity versions older than 0.4.0, but today this is unneeded.

Code snippet

https://github.com/AuroraDAO/idex/blob/4a05eb28e570e9820066474ff2adc924ce7a27bd/MyToken.sol#L72-L74

4. Conclusion

The audited smart contract is not safe to deploy.