<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

Metacade

In the contract `MetacadePresaleV2` 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 [fixme, describe what hacker can do and the impact].
![](https://accelerator-tasks-prod.s3.amazonaws.com/187834691c914e3ba4073fd58cdf8634/diagrams/centralization_MetacadePresale.v2-MetacadePresaleV2-owner.svg)

Centralization Risks in MetacadePresaleV2

- The contract `MetacadePresaleV2` interacts with third party contract with `IERC20` interface via `USDTInterface`.

```solidity=31
    IERC20 public USDTInterface;
```

---

- The contract `MetacadePresaleV2` interacts with third party contract with `IAggregator` interface via `aggregatorInterface`.

```solidity=32
    IAggregator public aggregatorInterface;
```

---

- The function `MetacadePresaleV2.resqueERC20` interacts with third party contract with `IERC20` interface via `_tokenAddress`.
  
```solidity=206
    function resqueERC20(address _tokenAddress, uint256 _amount) external onlyOwner {
```

Third Party Dependency

The type conversion `uint256(price * 1e10)` from type int256 to type uint256 may flip the value's sign:

```solidity=290
  return uint256(price * 1e10);
```

Unsafe Integer Cast

The order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern. A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

### External call(s)
```solidity=227
  _sendValue(payable(owner()), ethAmount);
```
* This function call executes the following external call(s).
* In `MetacadePresaleV2._sendValue`,
    * `(success) = _recipient.call{value: _weiAmount}()`

```solidity=229
  if (excess > 0) _sendValue(payable(_msgSender()), excess);
```

### State variables written after the call(s)
```solidity=233
  if (stepAfterPurchase>currentStep) currentStep = stepAfterPurchase;
```

```solidity=230
  totalTokensSold += _amount;
  _userDeposits[_msgSender()] += _amount * 1e18;
```

Check Effect Interaction Pattern Violated

The highlighted conditional logic does not seem necessary; in all cases the sale times will be the ones passed as arguments and the event will emit such information.

Furthermore, the `changeSaleTimes()` function is not checking whether `_endTime` is greater than `_startTime`.

Unnecessary and Missing Checks

The variables `USDTInterface` and `aggregatorInterface` assigned in the constructor can be declared as `Immutable` or even as constant. Immutable state variables can be assigned during contract creation, but will remain constant throughout the lifetime of a deployed contract. An advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they are not located in storage.

Variable Can Be Declared as Immutable

The contracts cited have an 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 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

`ClaimStartUpdated` is declared in `IMetacadePresaleV2` but never emitted.

```solidity=20
    event ClaimStartUpdated(
        uint256 prevValue,
        uint256 newValue,
        uint256 timestamp
    );
```

Unused Event

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

Missing Zero Address Validation

The word rescue is misspelled along the contract.

Typos In The Contract

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

Missing Emit Events

The linked variable declarations do not have a visibility specifier explicitly set. Inconsistencies in the default visibility the Solidity compilers impose can cause issues in the functionality of the codebase.

Visibility Specifiers Missing

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=26
    uint256[9] public token_amount;
```
- Variable `token_amount` is not in `camelCase`.


---
```solidity=27
    uint256[9] public token_price;
```
- Variable `token_price` is not in `camelCase`.


---
```solidity=28
    uint8 constant maxStepIndex = 8;
```
- Constant variable `maxStepIndex` is not in `UPPER_CASE`.


---
```solidity=31
    IERC20 public USDTInterface;
```
- Variable `USDTInterface` is not in `camelCase`.

Declaration Naming Convention

The first highlighted `require` statement will throw an error because the user is trying to buy more tokens than the maximum, not because the funds are not enough.

The second highlighted `require` statement will throw an error because the user is trying to calculate the price using an excessive amount, not because the amount is insufficient.

Incorrect Error Message

Shouldn't `configureClaim()` check if `_claimStart > block.timestamp` and other `startTime` and `endTime` possibilities? Is it possible to set `claimStart` with a lower value than `startTime`? Is it possible to set `claimStart` with a lower value than `endTime`? 

Shouldn't `configureClaim()` check `_claimStart > block.timestamp` && other `startTime` and `endTime` possibilities?

The highlighted comment says "...current step `amount`..." when "...current step `index`..." would better represent the `stepIndex` value.

Incorrect Comment

It is believed that the snippet below should include the case where `token_amount[stepIndex - 1] == totalTokensSold`:

```solidity=359
    if (token_amount[stepIndex - 1] < totalTokensSold) break;
```

Incorrect Current Step Calculation

Shouldn't `userDeposits()` check if `_user` has claimed the tokens in `previousPresale` and `betaPresale` contracts to avoid claiming more tokens than the ones bought? Right now this attack scenario does not seem feasible, but the highlighted code could eventually allow it.

Shouldn't `userDeposits()` check if `_user` hasClaimed the tokens in `previousPresale` and `betaPresale` contracts?

The following checks are missing:
- The length of `_token_amount` should be the same as the length of `_token_price`.
- `_endTime` should be greater than `_endTime`.

Missing Checks

`getLatestPrice()` makes use of the Chainlink's `latestRoundData()` function which does not check whether the return value contains outdated data. This could lead to stale prices according to the Chainlink documentation: https://docs.chain.link/data-feeds/price-feeds/historical-data
```solidity
 * @dev A timestamp with zero value means the round is not complete and should not be used.
```

Chainlink's `latestRoundData()` might return stale or incorrect results

Metacade - Audit 2

MetacadePresale.v2.sol

IMetacadePresale.v2.sol

Centralization Risks

Initial Token Distribution

OpenZeppelin Library Code Included in Source Code

Unnecessary Use of SafeMath

Centralized Control of Contract Upgrade

Third Party Dependencies

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

Uninitialized State Variable

Inconsistent Returned Variable

Comment Typos

Too Many Digits

Metacade - Audit

Metacade.sol

Presale.sol

CertiK KYC

Verified Contract

CertiK Skynet

Top 10% Security Score

Top 10% Code Security Score

Top 10% Governance Score

Top 10% Community Score

Top 10% Fundamental Score

The Metacade is the ultimate Web3 community hub where gamers and blockchain fanatics can communicate and collaborate.

Leaderboards

Due Diligence Tools

Resources

Bug Bounty Program