Read the findings of the 2022 Web3 Security Report

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.

Unlocked Compiler Version

The calculation of burn, redistribution, funding, and liquidity provision fees are derived from the `reflectedAmount` multiplied with the corresponding rates over 1000. However, the initial rates are too large, which two of them are larger than 1000:
```solidity=76
        fundingRate = 500;
        burnRate = 500;
        redistributionRate = 5000;
        liquidityProvisionRate = 1500;
```

Additionally, the conditions in the `require` of the function `setRate()` will not be satisfied, as the sum of these four rates should be less than 25. 

Lastly, in the function `getValues()`, `totalFees` is calculated using the formula `(trueAmount * feeRate) / 100`, where `feeRate` is the total rate. 

According to the Line 77 of `Eternal.withdraw()`, `uint256 netAmount = usingETRNL ? amount - (amount * eternal.viewTotalRate()) / 100000 : 0;`, the initial values seem reasonable.  

Inconsistent Initialization of Rates

In the contract `EternalToken`, the role `fund` has the authority over the following functions:
* `EternalToken.excludeFromReward(address account)`: Exclude the `account` from rewards.
* `EternalToken.includeInReward(address account) `: Include the `account` to rewards.
* `EternalToken.setRate(Rate rate, uint16 newRate)`: Update the rate of funding, burn, redistribution or liquidityProvision.
* `EternalToken.setLiquidityThreshold(uint64 value)`: Update the liquidity threshold.
* `EternalToken.setEternalLiquidity(address newContract)`: Update the address of the Eternal liquidity contract. 
* `EternalToken.designateFund(address _fund)`: Designate the `_fund` as the `fund` role.

The role `admin` has the authority over the following functions:
* `EternalToken.excludeFromReward(address account)`: Exclude the `account` from rewards.
* `EternalToken.includeInReward(address account) `: Include the `account` to rewards.
* `EternalToken.setRate(Rate rate, uint16 newRate)`: Update the rate of funding, burn, redistribution or liquidityProvision.
* `EternalToken.setEternalLiquidity(address newContract)`: Update the address of the Eternal liquidity contract.
* `EternalToken.designateFund(address _fund)`: Designate the `_fund` as the `fund` role.

Any compromise to these accounts may allow the hacker to manipulate the project. 

Centralization Related Risks in Contract `EternalToken`

All of the Eternal Tokens are sent to the role `admin` when deploying the contract. This could be a centralization risk as the `admin` can distribute Eternal tokens without obtaining the consensus of the community.

Initial Token Distribution

The declaration and use of local variables of type `uint16` and `uint64` on the aforementioned are inefficient as EVM operates with 32-byte values. The uint16` and `uint64` types have to be expanded to fit 32-byte costing extra gas.

Inefficient Use of `uint16` and `uint64`

In the aforementioned places of `EternalToken`, it uses `uint` to declare 256-bit unsigned integers, while it also uses `uint256` elsewhere. Although, `uint` is an alias for `uint256` and both represent the same underlying integer allocation. It is advisable that the complete form `uint256` should be used instead of the alias `uint` for clean coding practices. 

 Usage of `uint` Alias Instead of `uint256`

In error message of the `require` is that the input `newRate` must be positive. While it only checks `newRate >= 0`. In addition, it's better to set a threshold for `newRate`. 

Inaccurate Input Validation of `newRate`

The address `eternal` has never been initialized so it will be the zero address. Then all the operations related to the address `eternal` will not function properly. For example,
```solidity=71
        eternal.deposit(asset, _msgSender(), amount, id);
```
```solidity=105
        eternal.withdraw(_msgSender(), id);
```

Variable `eternal` Not Initialized

The variable `_users` in the constructor of the contract is initialized without any validation. 

Lack of Input Validation of `_users`

In the contract `Gage`, users can query user data by calling `Gage.viewUserData()`:
```solidity=144
    function viewUserData(address user) external view override returns (address, uint256, uint256, bool){
        UserData storage data = userData[user];
        return (data.asset, data.amount, data.risk, data.loyalty);
    }
```

If a user exits by calling `Gage.exit()`, `userData[user].inGage` will be updated to `false` with other fields remaining the same. In this case, the function `Gage.viewUserData()` will still return the user data before it exits, which might cause misunderstandings.

We would like to check with the Eternal team if this is the intended design.

Invisible User Status` inGage`

In the function `Gage.exit()`, the `status` is updated to `Closed` once the second-to-last user leaves. To deal with the last user's call of `Gage.exit()`, it's better to check if the status is `Closed` and `users == 1` at the end. If this is indeed the case, we can reduce the `users` to 0, withdraw the tokens for the last user, and possibly reset the gage to `Open` for reuse.

Otherwise, the last user can withdraw and exit, but the `users` is still 1 and the status is `Closed`. 

We would like to check with the Eternal team if this is the intended design. 

Abandoned Gage

The function `Gage.join()` changes the status of the gage to be `Active` once it is full. However, it does not check if the gage is `Active` or not at the beginning. In this case, it might be better to check if the gage is `Open` at the start of the `Gage.join()`. Without any proper status check, it may keep letting the users join the gage. 

We would like to advise the Eternal team to reconsider the design of the function `Gage.join()`.

Gage Might Be Full

The function `Gage.viewGageUserCount()` returns the current total number of users in the gage, but it requires the gage to be in the status `Active`. It seems to be unnecessary, because the status is set to be `Active` once the gage is full using the `Gage.join()` function. If some user leave the gage with `Gage.exit()`, it won't change the status until it's the second-to-last user. Hence, it's also helpful to view the number of users in the status `Active`. 

We would like to check with the Eternal team if this is the intended design. 

Invisible User Number For Active Gage

Eternal

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

13

0

5

1

7