In the contract `MoonNation` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.
![](https://accelerator-tasks-prod.s3.amazonaws.com/3eecc6d3ec63452b925060fca9c59e7e/diagrams/centralization_MoonNation__owner.svg)

In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.
![](https://accelerator-tasks-prod.s3.amazonaws.com/3eecc6d3ec63452b925060fca9c59e7e/diagrams/centralization_Ownable__owner.svg)

In the contract `Ownable` the role `_previousOwner` has authority over the functions shown in the diagram below.
Any compromise to the `_previousOwner` account may allow the hacker to take advantage of this authority.
![](https://accelerator-tasks-prod.s3.amazonaws.com/3eecc6d3ec63452b925060fca9c59e7e/diagrams/centralization_Ownable__previousOwner.svg)

Centralization Risks in MoonNationV2.sol

`384400000 * 10**9` tokens were sent to the `msg.sender` when deploying the contract. 
This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

When an account is included in the reward list through `includeInReward()`, the account's `rOwned` balance is not updated to reflect the change in `rTotal`. This may lead to a miscalculation of the account's deserved reward. For example, when an account on the reward list is excluded, it's `tOwned` balance would be locked for a period of time before the account is included back again. However, in that situation, the universal `rate` is likely to decrease in that period so that by reflecting the `rOwned` the account would receive more tokens than deserved which in effect cancels out that excluded period. So the `_rOwned[account]` should be updated to `reflectionFromToken(_tOwned[account])` instead of `_tOwned[account]`.

Incorrect `_rOwned[account]` Update

The `_previousTaxFee`, `_previousBurnFee` and `_previousMarketingAndDev` are used to restore the origin value of `_taxFee`, `_burnFee` and `marketingAndDevelopment` when the transfer is free. However, these variables are used to record the value before the update. This will cause `_taxFee`, `_burnFee` and `marketingAndDevelopment` to be updated to the pre-update value instead of the latest modified value once the transfer is free. So these variables should be updated in the function `removeAllFee()` instead of `setTaxFeePercent()`, `setBurnFeePercent()` and `setMarketingAndDevFeePercent()`.

Incorrect `_previousTaxFee`, `_previousBurnFee`  and `_previousMarketingAndDev` Update

An owner is possible to gain ownership of the contract even if he calls the function `transferOwnership` to transfer the ownership. This can be achieved by performing the following operations:
1. Call `lock` to lock the contract. The variable `_previousOwner` is set to the current owner.
2. Call `unlock` to unlock the contract.
3. Call `transferOwnership` to leave the contract without an owner. 
4. Call `unlock` to regain ownership.


Possible To Gain Ownership After Transferring The Contract Ownership

Addresses should be checked before assignment or external calls to make sure they are not zero addresses.

Missing Zero Address Validation

The variables `_taxFee`, `_burnFee`, `_maxTxAmount`, `_maxWalletToken`, `marketingAndDevelopment` do not have reasonable boundaries, so they can be given arbitrary values after deploying.

Lack of Reasonable Boundary

According to logic, only excluded accounts have `_tOwned`. So the `_burn` and `_marketingAndDev` should check if they are excluded before updating `_tOwned` to prevent unpredictable mistakes.

No Check Account  Is Excluded

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage of `public` and `external` Type

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

Redundant Code Components

Literals with many digits are difficult to read and review.

Too Many Digits

It is recommended to add `indexed` keyword for parameters in events, which makes it easier for users to navigate event logs.

Address Type Could Be Indexed In Events

Moon Nation V2 Addendum

MoonNationV2.sol

Possible To Gain Ownership After Renouncing The Contract Ownership

Moon Nation Game

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

14

0

2

0

12