Read the findings of the 2022 Web3 Security Report

In the contract `AXMV2` 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 and add and remove new minters, and transfer funds out.

![](https://accelerator-tasks-prod.s3.amazonaws.com/27dab85a70d64611a3551689e864cad9/diagrams/centralization-AXMV2-_owner.svg)

Furthermore, the role `minter` was also found to have authority over the following functions below:

- `mint()`
- `burn()`
- `add_dao_governance()`
- `del_dao_governance()`
- `get_dao_governance()`
- `add_dao_manage()`
- `del_dao_manage()`
- `get_dao_manage()`
- `setStatus()`
- `getMinSupply()`
- `setMinSupply()`
- `getInBurnRate()`
- `setInBurnRate()`
- `getInRewardRate()`
- `setInRewarcRate()`
- `getOutBurnRate()`
- `setOutBurnRate()`
- `getOutRewardRate()`
- `setOutRewardRate()`
- `addPair()`
- `delPair()`
- `getPair()`
- `setReward()`

Any compromise to the `minter` accounts may allow the hacker to take advantage of this authority and mint or burn `AXMV2` tokens, 

Centralization Risk in AXMV2_TOKEN.sol

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

Initial Token Distribution

We noticed that there is no limit on the number of `AXM tokens` according to function `mint()`. 

```solidity=55
    // mint with max supply
    function mint(address _to, uint256 _amount) public onlyMinter returns (bool) {
        // if (_amount.add(totalSupply()) > maxSupply) {
        //     return false;
        // }
        // require(_amount.add(totalSupply()) <= maxSupply, "AXMV2: mint amount over max allow");
        _mint(_to, _amount);
        return true;
    }
```

Since the `_to` address is unknown, there is also the centralization problem of issuing coins to any address.

No Limit On Minting

`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 function that affects the status of sensitive variables should be able to emit events as notifications. The following functions were found to be missing event emissions:
- `addMinter()`
- `delMinter()`
- `del_dao_governance()`
- `add_dao_manage()`
- `del_dao_manage()`
- `setStatus()`
- `setMinSupply()`
- `setInBurnRate()`
- `setInRewarcRate()`
- `setOutBurnRate()`
- `setOutRewardRate()`
- `addPair()`
- `delPair()`
- `setReward()`

Missing Emit Events

Performing integer division before multiplication truncates the low bits, losing the precision of calculation.

One instance of a division before a multiplication, found on line 233:
```solidity=233
            burn_fee = amount.div(10000).mul(out_burn_rate);
```

Divide Before Multiply

Boolean constants can be used directly and do not need to be compared to true or false.

Comparison to Boolean Constant

The return value of an external call is not stored in a local or state variable.

Unused Return Value

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 linked declarations do not conform to the [Solidity style guide](https://solidity.readthedocs.io/en/v0.7.3/style-guide.html#naming-conventions) with regards to its naming convention. 

Particularly:
- `camelCase`: Should be applied to function names, argument names, local and state variable names, modifiers
- `UPPER_CASE`: Should be applied to `constant` variables
- `CapWords`: Should be applied to contract names, struct names, event names and enums

Declaration Naming Convention

Literals with many digits are difficult to read and review.

Too Many Digits

There are several typos in the code and comments.

Typos in Code and Comments

It is believed that the development team wanted to call `delMinter()` here.

Remove from minters when adding DAO Governance

The following getter functions were found to be only accessible by the accounts with minter role:

- `get_dao_governance()`
- `get_dao_manage()`
- `getMinSupply()`
- `getInBurnRate()`
- `getInRewardRate()`
- `getOutBurnRate()`
- `getOutRewardRate()`
- `getPair()`

Permissioned Getters

Are the highlighted initializations required if the constructor would overwrite them during deployment?

MetaLife

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

15

0

15

0

0