IDEX

Integer overflow/underflow occur when an integer hits its bit-size limit. Every integer has a set range; when that range is passed, the value loops back around. A clock is a good analogy: at 11:59, the minute hand goes to 0, not 60, because 59 is the largest possible minute. Integer overflow and underflow may cause many unexpected kinds of behavior and was the core reason for the `batchOverflow` attack.

* `contracts/Exchange.sol`: `wallet` should be checked to be different from `0x0` in `loadBalanceInAssetUnitsByAddress`, `loadBalanceInPipsBySymbol`, and `loadBalanceInAssetUnitsBySymbol`. * `contracts/Governance.sol`: Functions `setCustodian`, `initiateExchangeUpgrade`, and `initiateGovernanceUpgrade` do not check if the given address parameter is a contract. * `libraries/AssetRegistry.sol`: Function `registerToken` does not check if `tokenAddress` is different from `0x0`. Moreover, it does not check if `tokenAddress` is a contract address. * `libraries/AssetRegistry.sol`: Function `registerToken` does not check if symbol is different from the empty string.

Since Solidity 0.4.22, some non-ERC20 compliant token contracts that used to work in older versions no longer work now. Since many token contracts implement the `transfer` function by either returning `true` or reverting the call altogether, some contract developers deemed the return value unnecessary, writing contracts with a `transfer` function with signature `function transfer(address to, uint amount) public { ... }`. All non-ERC20 compliant contracts like the latter case that used to work before 0.4.22 will fail in IDEX, as it relies on Solidity 0.6.8. More info can be found [here](https://medium.com/@chris_77367/explaining-unexpected-reverts-starting-with-solidity-0-4-22-3ada6e82308c).

Contrary to the comment on L546, calling `exitWallet` does not immediately disable deposits. Deposits may still occur after one calls `exitWallet` if deposit transactions are mined first (e.g, if they are given higher gas).

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.4.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked." For consistency and to prevent unexpected behavior in the future, it is recommended to remove the caret to lock the file onto a specific Solidity version.

* `SafeMath` is imported but never used. * `IERC20` is imported but never used.

The `depositEther()` function is payable and can receive arbitrary amounts of `ether`. This function calls `deposit()`, which first converts the amount to pips and then back into `ether`. Such conversion is required so that the transfer of `ether` to the Custodian contract does not contain the “dust”, i.e. values lower than 1/10^8 `ether`. However, the dust is locked in the `Exchange` contract for each user deposit, without letting users ever having them back.