Read the findings of the 2022 Web3 Security Report

The COSMIC MISSION Protocol is a decentralized finance(Defi) token deployed on the BSC. 

50,000,000 tokens will be minted to the contract deployer(`root`) when deploying. 2,500,000 tokens will be transferred from `root` to `whiteList`, 2,500,000 tokens will be transferred from `root` to `dao`. 

The remaining 45,000,000 tokens will be locked for several years and unlocked one after another over a period of years. 37,500,000 tokens will be locked for 4 years, 7,500,000 tokens unlocked per year, the first unlock time is when deployed. 7,500,000 tokens will be locked for 38 months, 208,333 tokens unlocked per month, the first unlock time is three months after deployment.

If the sender is not `root` and `totalSupply` > 20,000,000, a fee will be charged for the transfer process. Two types of fees exist. When `totalSupply` - 20,000,000 > 5% of the transfer amount, a 5% fee will be charged on each transfer. The 2% fee will be transferred to account `pool`. The 3% fee will be burned. When `totalSupply` - 20,000,000 <= 5% of the transfer amount, `totalSupply` - 20,000,000 tokens will be burned.

Financial Models

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 variables are assigned only once, either during their contract-level declaration or during the `constructor`'s execution.

Mutability Specifiers Missing

Literals with many digits are difficult to read and review.

Too Many Digits

The modifier `onlyOwner` is declared but never be used in contract `Token`.

Unused Modifier

```solidity=91
    uint256 amount = mechanismAmount;

    if(mechanismLock<amount) amount = mechanismAmount;
```
The assignment in Line91 and Line93 are the same. It's not logical.

Incorrect Assignment

There are many hardcode addresses in this codebase.

Hardcode Address

`mechanismAmount` * `mechanismCount` == 7499988*10**6, which is less than `mechanismLock`. After 36 calls to the function `unlockMechanism`, there are `12*10**6` `CM` not transferred from `root` to `mechanism`.

Inaccurate Data

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

Initial Token Distribution

`unlockMechanism` and `unlockMining` are functions with similar logic. In function `unlockMining`, there is a check to ensure `miningCount` > 0, and there is no such check in function `unlockMechanism`. We think the checks in these two functions need to be consistent. In the function `_transfer`, `miningCount` > 0 and `mechanismCount` >0 has been checked, so we think the check `require(miningCount > 0 , "ERC20: not count");` in function `unlockMining` can be removed.

Inconsistent Checks

In function `_transfer`, if the sender is not `root`, a 5% fee will be charged. But the amount deducted from the sender account and the amount added to the recipient account is the same. The fee should be deducted from the sender's account. The recipient can get the remaining amount. The current calculation method is incorrect.

Incorrect Transfer Amount

COSMIC MISSION

projects

COSMIC MISSION

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

11

0

3

0

8