Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

In the contract `CapsuleConverter` 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/59abb00ad6d34d4dba79c684d13750a3/diagrams/centralization_CapsuleConverter__owner.svg)

Centralization Risks in CapsuleConverter.sol

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

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

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

Centralization Risks in CrownDAOLogic.sol

The state variables `generationsMax`, `currentQuota`, and `maxSupply` can be changed and have no limitations. So they can be set to an arbitrary number.

Lack of reasonable boundary

According to the following code:
```solidity
function getNFT(
        uint256 intialRandom,
        uint256 _day
    ) internal {
        uint256 pseudoRandom = intialRandom % counter;
        pseudoRandom += startIndex;

        _day = _day;

        if (openMapping[pseudoRandom] != 0) {
            monsterNFT.mint(msg.sender, openMapping[pseudoRandom]);
            dailyMonster[_day] = openMapping[pseudoRandom];
        } else {
            monsterNFT.mint(msg.sender, pseudoRandom);
            dailyMonster[_day] = pseudoRandom;
        }
        if (openMapping[startIndex + counter - 1] != 0) {
            openMapping[pseudoRandom] = openMapping[startIndex + counter - 1];
        } else {
            openMapping[pseudoRandom] = startIndex + counter - 1;
        }
        counter--;
        if (counter == 0) {
            //Change startIndex
            startIndex += 500;
            //Set counter again
            counter = 500;
        }
    }
```
, the function is used to mint `monsterNFT` with a random id, however, the id of `monsterNFT` could be duplicated under this calculation, which would cause mint failure and gas wasting.

Logical issue in `getNFT()`

The `random` number generation is based on the result of `keccak256` encryption of data that is easy to control or get. The result can be controlled by the caller of the transaction.

The block difficulty or timestamp is not a good source of randomness. They can be manipulated if the attacker is also a miner. 

Weak pseudo random number 

The `monsterNFT` would be minted in both `CapsuleConverter` and `MintAuction`, hence the token with the same id may be minted in both contracts, which would cause mint failure and gas wasting.

The `monsterNFT` may be minted with the same id 

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

In the above-mentioned functions, the call of transferFrom should be approved in advance, 
otherwise the transactions may fail.

Transfer should be approved

In the contract `MintAuction` 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/59abb00ad6d34d4dba79c684d13750a3/diagrams/centralization_MintAuction__owner.svg)

Centralization Risks in MonsterAuction.sol

The onlyOwner function `setMonstersForDailyAction()` will be called in side the function `execute()`. In this case, the msg.sender of the call will be the current contract(address(this)).
Then this call will be failed.

Additionally, the function `setMonstersForDailyAction()` should be `internal`. Otherwise, the function can be called more than once every day.



Logical issue of the function `setMonstersForDailyAction`

The function `execute()` could be called more than once every day. 
We would like to confirm with the client whether this implementation aligns with the original design.

Potential multiple calls of `execute()` every day

According to the current code logic, the timing of the function call `execute()` is not clear. As a result, this would cause several logical issues.

e.g.

The below state variables are modified when `placeBid()` is called.
```solidity
    address public highestBidder1;
    uint256 public highestBid1;
``` 
And they will be re-set to default when the function `execute()` is called.

They should be re-set to default every day. If not, the bids on the second day will have problems.
After the function `execute()` is called, the bid for the current day should be forbidden.

Potential bidding failures

The function `execute()` would only be called by the `owner` to transfer the `monsterNFT` to the daily winner, however, this function should not be called if `dailyMonster[_day]` or `winner1` have not been generated yet. Besides, all the winners would not get the daily  `monsterNFT` until the `owner` call this function.

Logical issue in `execute()`

Code commented in both Spanish and English.

Code comments in two languages

`setMonstersForDailyAction` should be `setMonstersForDailyAuction`, and `intialRandom` should be `initialRandom`.

Typos in parameter and function names

In the function `placeBid`, the pass-in value `_monster` should be the same as `_monsterId`, hence it is redundant.

The use of `_monster`

The `maxNumberToMint` is initialized but never used, hence it is redundant.

Redundant Variable

In the contract `MonsterCapsule` 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/59abb00ad6d34d4dba79c684d13750a3/diagrams/centralization_MonsterCapsule__owner.svg)

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

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

Centralization Risks in MonsterCapsule.sol

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

Initial Token Distribution

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

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

Centralization Risks in M2MonstersDAOExecutor.sol

The `MINIMUM_DELAY` equals 0, hence the lock time could be set as zero, and the Timelock mechanism would be disabled in that case.

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

Centralization Risks in M2MonstersDAOProxy.sol

In the contract `MonsterNFT` 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/59abb00ad6d34d4dba79c684d13750a3/diagrams/centralization_MonsterNFT__owner.svg)

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

Centralization Risks in MonsterNFT.sol

The variable `miscSetting` is defined and could be set to given values, however, the variable has never been used in other places.

M2 Monsters DAO

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

24

0

15

0

9