Read the findings of the 2022 Web3 Security Report

In the contract `MADCROW` 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/fad5bfdba8574e30a55905d80bd3d83a/diagrams/centralization_MADCROW__owner.svg)

Centralization Risks in MadCrows.sol

In the contract `MADCROW`, the implementation of the contract `mad` is unknown. The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc. Third-party related functions are not in the scope of this audit.

Unknown implementations

The state variables `startPrice`, `lastPrice`,  `startDate` and `endDate` can be changed and have no limitations. So they can be set to an arbitrary number.

Key Metrics can be Changed without Limitations

The `startPrice`, `startDate`, and `endDate` could be set to an arbitrary number, hence the selling process may not proceed as users expected. Besides, the `endDate` is not the actual ending time as its literal meaning.

e.g., the following situations could happen:
1. Modifying the `startPrice` to a large value in the middle of the selling, the price would immediately rise.
2. Changing the `endDate` to a number before the current time, the price will immediately reach the `endPrice` or may even overflow when calculating `getCurrentPrice()`.
3. Changing the `startDate` to a number near the current time, the price will immediately be increased to the `startPrice`, or revert `SaleNotStarted()`.
4.  Modifying the `startPrice` to a large value when selling the last token, the `lastPrice` could rise to a large number and users would fail to refund.

Logical issue of changing `startPrice`,  `startDate` and `endDate`

The return value of the transfer()/transferFrom() call is not checked.

```solidity
        mad.transferFrom(_msgSender(),address(this),totalPrice);
```

```solidity
        mad.transfer(_msgSender(),teamAmount);
```

```solidity
        mad.transfer(DEAD,burnAmount);
```

```solidity
        mad.transfer(_msgSender(),amount);
```

```solidity
        mad.transfer(_msgSender(),toSend);
```

```solidity
        mad.transfer(_msgSender(),airdropAmount);
```

```solidity
        mad.transfer(_msgSender(),toSend);
```

```solidity
        mad.transfer(_msgSender(),toSend);
```



Unchecked ERC-20 `transfer()`/`transferFrom()` Call

In the contract `MADCROW`, users send `mad` tokens at current prices to the contract to buy the NFT. If all of the 3333 NFTs were sold out, 1/4 of the `mad` tokens in the contract will be transferred to the `owner`, and 1/2 will be burnt. Besides, `mad` tokens in the contract will also be airdropped in terms of the `crocrow` token amount a user has, as a result, if the total supply of `crocrow` tokens is large enough, some of the `crocrow` token holders may fail to call the airdrop functions since the insufficient `mad` tokens in the contract.

Insufficient `mad` token

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 could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared as `constant`

One or more 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

```solidity
        bytes memory _data
```
- Parameter `_data` is not in `camelCase`.

```solidity
    function walletOfOwner(address _owner) public view returns (uint256[] memory) {
```
- Parameter `_owner` is not in `camelCase`.

```solidity
    function refundMulticheck(address _owner) public view returns (uint256) {
```
- Parameter `_owner` is not in `camelCase`.

```solidity
    function airdropMulticheck(address _owner) public view returns (uint256) {
```
- Parameter `_owner` is not in `camelCase`.



Declaration Naming Convention

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 `lastPrice` will be updated when minting the last token, and will only be used after all of the tokens were sold out, hence it is redundant to call the `changeEndPrice()` to change `lastPrice` before all of the tokens were sold out.

Redundant to change `lastPrice`

In the contract `MADCROW`, all of the `mad` tokens used to buy NFT, of which the part that exceeds the `lastprice` can be refunded after `soldout`. Besides, the `owner` and users are not able to call the `withdraw()`, `refund()`, `refundAll()`, `claimAirdrop()`, `claimAirdropAll()` and `claimAirdrop100()` before all of the tokens are sold out, which would result in a large amount of `mad` tokens stuck in the contract before the last NFT token is sold.

Design of the tokenomics

MAD CROWS

IERC165.sol

MadCrows.sol

IERC20.sol

IERC721Receiver.sol

README.md

CRO CROW

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