Ecoin Finance

The mapping `_balances` is defined as `PRIVATE` in `@openzeppelin/contracts/token/ERC20/ERC20.sol` but it is defined as `INTERNAL` in E-Coin `Finance/projects/contracts/EcoinToken/ERC20.sol`. The contract `Ecoin.sol` imports the `OpenZeppelin` `ERC20` contract, therefore the `Ecoin.sol` cannot read the mapping `_balances` which will lead to a compiler issue.

Sensitive functions such as `_transfer` are dependent on the senders or receiver `_attributeMap`.

Multiple Solidity versions are used in the codebase. The versions used are: - `^0.8.11` - `^0.8.0` - `^0.8.5`

All variable types within Solidity are initialized to their default \""empty\"" value, which is usually their zeroed out representation. Particularly: - `uint` / `int`: All `uint` and `int` variable types are initialized at `0` - `address`: All `address` types are initialized to `address(0)` - `byte`: All `byte` types are initialized to their `byte(0)` representation - `bool`: All `bool` types are initialized to `false` - `ContractType`: All contract types (i.e. for a given `contract ERC20 {}` its contract type is `ERC20`) are initialized to their zeroed out address (i.e. for a given `contract ERC20 {}` its default value is `ERC20(address(0))`) - `struct`: All `struct` types are initialized with all their members zeroed out according to this table

The contract has 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 an 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.

*Note* The comment on line 281 reads, "Special trade between defined wallets." It seems that transfers from investors are subject to a fee. In the function `_transfer()` the variable `feeAmount` is set to 0. Then the function checks if the sender and receiver are exempt from fees. We are assuming that most investors will not be exempt from fees, hence line 280 will evaluate to true and then the function will check line 281. From the comment above we assume that most trades between investors will not fit the description of a `special trade`. Therefore we believe this nested if statement will evaluate to false which will in turn leave `feeAmount` equal to zero. In all this would result to most transfers being tax free.