Kanga Exchange

According to [EIP-20](https://eips.ethereum.org/EIPS/eip-20), transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. However, both `transfer()` and `transferFrom()` will return `false` and not emit an event if the input `_value` is 0.

The ERC-20 `approve` function has a well-known race condition whereby an adjustment of an existing approval can be exploited to utilize the full amount of the previously set approval as well as the newly set approval by monitoring the transaction mempool. See also [ERC20 API: An Attack Vector on Approve/TransferFrom Methods](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#heading=h.m9fhqynw2xvt)

Solidity frequently releases new compiler versions. Using an old version prevents access to new Solidity security features. In addition the contracts have an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging, as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Literals with many digits are difficult to read and review.

Both functions `transfer()` and `transferFrom()` return false instead of reverting on failure. This conforms to the ERC-20 standard, but it is often mistakingly assumed that these functions will revert on failure.

The modifier `isOwner()` is declared but never used in the contract.