---
title: CertiK Final Report For Base Protocol
tags: final-report
---
<div><div style="background-image:url(https://i.imgur.com/n9A7QyA.png); height: 800px;background-position: center; background-repeat: no-repeat;background-size: cover;"><div style="position: relative;top: 25%;left:5.6%;line-height: 2.5em; color: white;">
<p style="font-size: 28px">Base Protocol</p>
<p style="font-size: 22px">Security Assessment</p>
<p style="font-size: 16px; line-height: 3em">January 17th, 2021</p></div><div style="position: relative;top: 44%;left:5.6%; color: #8D8D8D;">For : <p style="font-size: 12px; color: #C6CCD3">Base Protocol</p>
<p style="font-size: 11px;color: #C6CCD3; line-height: 1.5rem;">By :</p>
<p style="font-size: 12px; line-height: 0.5rem; color: #C6CCD3;">Owan Li @ CertiK</p>
<p style="font-size: 12px; line-height: 0.055rem; color:#F6AA42">[e-mail]</p>
<br/>
<p style="font-size: 11px; line-height: 0.5rem; color: #C6CCD3;">Bryan Xu @ CertiK</p>
<p style="font-size: 12px; line-height: 0.03rem; color:#F6AA42">[e-mail]</p></div></div></div>

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Disclaimer

CertiK reports are not, nor should be considered, an “endorsement” or “disapproval” of any particular project or team. These reports are not, nor should be considered, an indication of the economics or value of any “product” or “asset” created by any team or project that contracts CertiK to perform a security review.

CertiK Reports do not provide any warranty or guarantee regarding the absolute bug-free nature of the technology analyzed, nor do they provide any indication of the technologies proprietors, business, business model or legal compliance.

CertiK Reports should not be used in any way to make decisions around investment or involvement with any particular project. These reports in no way provide investment advice, nor should be leveraged as investment advice of any sort.

CertiK Reports represent an extensive auditing process intending to help our customers increase the quality of their code while reducing the high level of risk presented by cryptographic tokens and blockchain technology.

Blockchain technology and cryptographic assets present a high level of ongoing risk. CertiK’s position is that each company and individual are responsible for their own due diligence and continuous security. CertiK’s goal is to help reduce the attack vectors and the high level of variance associated with utilizing new and consistently changing technologies, and in no way claims any guarantee of security or functionality of the technology we agree to analyze.

### What is a CertiK report?

* A document describing in detail an in depth analysis of a particular piece(s) of source code provided to CertiK by a Client.
* An organized collection of testing results, analysis and inferences made about the structure, implementation and overall best practices of a particular piece of source code.
* Representation that a Client of CertiK has indeed completed a round of auditing with the intention to increase the quality of the company/product’s IT infrastructure and or source code.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Overview

#### Project Summary

<table>
<tr>
<td width="50%" valign="top"><b>Project Name</b></td>
<td width="50%" valign="top"><a href="https://github.com/Base-Protocol/contracts-0.6.12/tree/master/contracts">CascadeV2</a></td>
</tr>
<tr>
<td width="50%" valign="top"><b>Description</b></td>
<td width="50%" valign="top">A liquidity mining contract</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Platform</b></td>
<td width="50%" valign="top">Ethereum; Solidity; Yul</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Codebase</b></td>
<td width="50%" valign="top"><a href="https://github.com/Base-Protocol/contracts-0.6.12/blob/master/contracts/CascadeV2.sol">GitHub Repository</a></td>
</tr>
<tr>
<td width="50%" valign="top"><b>Commit</b></td>
<td width="50%" valign="top">
<a href="https://github.com/Base-Protocol/contracts-0.6.12/commit/d384fe047aa3d58b1dd83721d7ec61f3f8b1432d">
d384fe047aa3d58b1dd83721d7ec61f3f8b1432d</a><br/>
<a href="https://github.com/Base-Protocol/contracts-0.6.12/commit/77ba0bd903e3392dda67c2bd0b132e47b53b6ffe">
77ba0bd903e3392dda67c2bd0b132e47b53b6ffe</a><br/>
<a href="https://github.com/Base-Protocol/contracts-0.6.12/commit/b563d899aa03ab346d0fd8b3843926c4e3052725">
b563d899aa03ab346d0fd8b3843926c4e3052725</a><br/>
<a href="https://github.com/Base-Protocol/contracts-0.6.12/commit/4c029e72ce6ef69888bd5850ef7066eb96e62cdd">
4c029e72ce6ef69888bd5850ef7066eb96e62cdd</a><br/>
</td>
</tr>
</table>

#### Audit Summary

<table>
<tr>
<td width="50%" valign="top"><b>Delivery Date</b></td>
<td width="50%" valign="top">Jan. 17th, 2021</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Method of Audit</b></td>
<td width="50%" valign="top">Static Analysis, Manual Review</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Consultants Engaged</b></td>
<td width="50%" valign="top">2</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Timeline</b></td>
<td width="50%" valign="top">Jan. 8, 2021 - Jan. 12, 2021</td>
</tr>
</table>

#### Vulnerability Summary

<table>
<tr>
<td width="50%" valign="top"><b>Total Issues</b></td>
<td width="50%" valign="top">10</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Total Critical</b></td>
<td width="50%" valign="top">0</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Total Major</b></td>
<td width="50%" valign="top">2</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Total Minor</b></td>
<td width="50%" valign="top">2</td>
</tr>
<tr>
<td width="50%" valign="top"><b>Total Informational</b></td>
<td width="50%" valign="top">6</td>
</tr>
</table>

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Executive Summary

This report has been prepared for **CascadeV2** smart contract to discover issues and vulnerabilities in the source code of their Smart Contract as well as any contract dependencies that were not part of an officially recognized library. A comprehensive examination has been performed, utilizing Dynamic Analysis, Static Analysis, and Manual Review techniques.

The auditing process pays special attention to the following considerations:

* Testing the smart contracts against both common and uncommon attack vectors.
* Assessing the codebase to ensure compliance with current best practices and industry standards.
* Ensuring contract logic meets the specifications and intentions of the client.
* Cross referencing contract structure and implementation against similar smart contracts produced by industry leaders.
* Thorough line-by-line manual review of the entire codebase by industry experts.

<!-- Additionally, it’s important to identify what trust is expected/required between various actors.
This is particularly important given the anonymous nature of the developer team. Users of the
system must be aware of the following capabilities of the administrators: -->
Additionally, to bridge the trust gap between administrator and users, administrator needs to express a sincere attitude with the consideration of the administrator team's anonymousness. The administrator has the responsibility to notify users with the following capability of the administrator:

* Administrators can transfer assets in this contract under unpredicted cases via 'adminRescueTokens' method
* Administrators have privilege to update thec address of implementation of cascadeV1 interface via 'SetCascadeV1' method

The advantage of 'adminRescueTokens' method in the protocol is that the administrator reserves the ability to rescue the assets in this contract under unexpected cases. It is also worthy of note the downside of 'adminRescueTokens' method, where the treasury in this contract can be migrated to any addresses.

To improve the trustworthiness of the project, any dynamic runtime changes on the protocol should be notified to clients. Any plan to call this 'adminRescueTokens' method is better to move to the execution queue of Timelock, and also emit events.

<!-- Furthermore, the 'CascadeV2.migrate' function can only be called by address `cascadeV1`. This address can be changed by the administrator, although it will emit events when it's changed. Clients should be cautious on the change of this address since depoist info can be manipulated by this function if it's not called by Cascade(V1) contract. -->

Furthermore, the invocation of the ‘migrate’ function requires that the caller must be from the address of `cascadeV1`, which can be modified via invocation of ‘SetCascadeV1’ method by the administrator. Although the administrator has already set the emit event to alert any of the ‘SetCascadeV1’ invocations, the address is possible to be changed by human error or malicious manipulations by internal team. As mentioned above, we also strongly recommend all contract manipulations must move to the execution queue of Timelock.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> File in Scope

|ID| Contract | SHA-256 Checksum | Commit |
| ----------------- |----------------- | ------------------------------------------------------------ | ---------------------------------------- |
| **CAS** | **CascadeV2.sol** | 3921ec1385eb047e04e58ed843d414e9bec6587f1614bcfa8d8f51614464c7a4 | 4c029e72ce6ef69888bd5850ef7066eb96e62cdd |

---

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Documentation

The sources of truth regarding the operation of the contracts in scope were lackluster and are something we advise to be enriched to aid in the legibility of the codebase as well as project. To help aid our understanding of each contract’s functionality we referred to in-line comments and naming conventions.

These were considered the specification, and when discrepancies arose with the actual code behaviour, we consulted with the **CascadeV2** team or reported an issue.

---

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Review Notes

Certain optimization steps that we pinpointed in the source code mostly referred to coding standards and inefficiencies, however 2 major and 2 minor vulnerabilities were identified during our audit that solely concerns the specification.

Certain discrepancies between the expected specification and the implementation of it were identified and were relayed to the team, however they pose no type of vulnerability and concern an optional code path that was unaccounted for.

The project has adequate doumentation and specification outside of the source files, also the code comment coverage is detailed.

---

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Recommendations

Overall, the codebase of the contracts should be refactored to assimilate the findings of this report, enforce linters and / or coding styles as well as correct any spelling errors and mistakes that appear throughout the code to achieve a high standard of code quality and security.

-

## <img src="https://svgshare.com/i/Pp1.svg" width="40"/> Findings

| ID | Title | Type | Severity | Resolved |
| ---------: | ----------------------------------------------- | ----------------------- | ------------- | ------------------------------------------------------------ |
| CAS-01 | Incorrect Naming Convention Utilization | Coding Style | Informational | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-02 | State variables that could be declared constant | Gas Optimization | Informational | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-03 | Proper Usage of “public” and “external” type | Gas Optimization | Informational | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-04 | Missing Emit Events | Optimization | Minor | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-05 | Missing Checks | Logical Issue | Minor | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-06 | Missing Condition Checks | Gas Optimization | Informational | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-07 | Deposit and Withdraw Restrictions | Optimization | Major | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-08 | Logic issue in `withdrawLPTokens()` | Volatile Code | Major | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |
| CAS-09 | Code Redundancy and Inefficiency | Dead Code | Informational | <img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:3%;" /> |

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-01" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-01: Incorrect Naming Convention Utilization

| Type | Severity | Location |
| ------------ | ------------- | ---------------------------------- |
| Coding Style | Informational | [CascadeV2.sol L10-12,L29,L53 ](#) |

#### Description:

Solidity defines a naming convention that should be followed. In general, parameters should use mixedCase, refer to: https://solidity.readthedocs.io/en/v0.6.12/style-guide.html#naming-conventions

Variables shoud use mixedCase.
Examples:
Variables like: `userDeposits_numLPTokens`, `userDeposits_depositTimestamp`, `userDeposits_multiplierLevel`,`BASE`

Functions other than constructors should use mixedCase.
Examples:
Functions like: `setBASEToken()`

#### Recommendation:

The recommendations outlined here are intended to improve the readability, and thus they are
not rules, but rather guidelines to try and help convey the most information through the names
of things.

#### Alleviation:

The team heeded our advice and renamed the variables with mixedCase.
The recommendations were applied in commit b563d899aa03ab346d0fd8b3843926c4e3052725.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-02" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-02: State variables that could be declared constant

| Type | Severity | Location |
| ---------------- | ------------- | -------------------------- |
| Gas Optimization | Informational | [CascadeV2.sol L25,L26](#) |

#### Description:

Below variables are not initialized before usage.
If they are constants, better to define as constants. Constant state variables should be declared constant to save gas.

    uint256 public rewardsStartTimestamp;
    uint256 public rewardsDuration;

#### Recommendation:

We recommend to change the codes like below:

    uint256 public constant rewardsStartTimestamp = 123456;
    uint256 public constant rewardsDuration = 1234567;

#### Alleviation:

These two variables were removed in commit 77ba0bd903e3392dda67c2bd0b132e47b53b6ffe.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-03" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-03: Proper Usage of "public" and "external" type

| Type | Severity | Location |
| ---------------- | ------------- | ------------------------------------------------ |
| Gas Optimization | Informational | [CascadeV2.sol L46,L53,L60,L75,L95,L154,L230](#) |

#### Description:

"public" functions that are never called by the contract could be declared "external" . When the inputs are arrays "external" functions are more efficient than "public" functions.
Examples:
Functions `initialize()`,`setLPToken()`, `setBASEToken()`, `adminRescueTokens()`, `deposit()`, `withdrawLPTokens()`, `upgradeMultiplierLevel()`, `owedTo()` in contract `CascadeV2`.

#### Recommendation:

Consider using the "external" attribute for functions never called from the contract.

#### Alleviation:

The team heeded our advice and used the "external" attribute for functions never called from the contract.
The recommendations were applied in commit b563d899aa03ab346d0fd8b3843926c4e3052725.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-04" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-04: Missing Emit Events

| Type | Severity | Location |
| ------------ | -------- | -------------------------- |
| Optimization | Minor | [CascadeV2.sol L46,L53](#) |

#### Description:

Several sensitive actions are defined without event declarations.

Examples:
Functions like : `setLPToken()` , `setBASEToken`.

#### Recommendation:

Consider adding events for sensitive actions, and emit it in the function like below.

    event SetLPToken(address indexed _lpToken);
    function setLPToken(address _lpToken) public onlyOwner
    {
        lpToken = IERC20(_lpToken);
        emit SetLPToken(_lpToken);      
    }

#### Alleviation:

The team heeded our advice and added events for sensitive actions.
The recommendations were applied in commit b563d899aa03ab346d0fd8b3843926c4e3052725.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-05" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-05: Missing Checks

| Type | Severity | Location |
| ------------- | -------- | -------------------------------------------- |
| Logical Issue | Minor | [CascadeV2.sol L46,L53,L75,L95,L154,L199](#) |

#### Description:

Functions `deposit()` and `withdrawLPTokens()` are missing parameter value checks.
Function `upgradeMultiplierLevel()` is missing array length checks.
Functions `setLPToken()`, `setBASEToken()` and `getUpdatedDepositSeconds()` are missing address zero checks.

#### Recommendation:

We recommend to add neccessary checks, for example:

    function deposit(uint256 amount) public {
        ...
        require(amount <= allowance, "allowance");
        require(amount != 0, "zero amount");
        ...
    }
    function upgradeMultiplierLevel(uint256[] memory deposits) public {
        require(deposits.length != 0, "deposits array is empty");
        updateDepositSeconds(msg.sender);
        ...
    }
    function setLPToken(address _lpToken) public onlyOwner {
        require(_lpToken != address(0), "address is zero");
        lpToken = IERC20(_lpToken);
    }
    ...

#### Alleviation:

The team heeded our advice and added neccessary checks for all the functions we listed in this Exhibit.
The recommendations were applied in commit b563d899aa03ab346d0fd8b3843926c4e3052725.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-06" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-06: Missing Condition Checks

| Type | Severity | Location |
| ---------------- | ------------- | ----------------------- |
| Gas Optimization | Informational | [CascadeV2.sol L163](#) |

#### Description:

For Level 3 , functions `upgradeMultiplierLevel()` has no control flow case , so it will go through all three `if` cases and return.

#### Recommendation:

We recommend to add a condition like below:

    if (age <= 30 days || userDeposits_multiplierLevel[msg.sender][idx] == 3) {
        continue;
    }

#### Alleviation:

The team heeded our advice and added the condition.
The recommendations were applied in commit b563d899aa03ab346d0fd8b3843926c4e3052725.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-07" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-07: Deposit and Withdraw Restrictions

| Type | Severity | Location |
| ------------ | -------- | -------------------------- |
| Optimization | Minor | [Cascade.sol L187,L256](#) |

#### Description:

The Cascade.sol is not in the scpoe of this audit, but it is involved with CascadeV2.migrate function.

/**
 * @notice Called by Cascade v1 to migrate funds into Cascade v2.
...
 */
 function migrate(
        address user,
        uint256 numLPTokens,
        uint256 numRewardTokens,
        uint8   multiplier,
        uint256 depositTimestamp,
        uint256 depositSeconds
    )
        external
    {
        require(msg.sender == cascadeV1, "only cascade v1");
        ...
    }

Hence we checked the logic in Cascade.sol.
Both `deposit()` and `withdrawLPTokens()` functions have the same code as below:

 require(deposits_lastMultiplierUpgradeTimestamp[msg.sender] == 0, "multiplied too recently");

It means users cannot call `deposit()` or `withdrawLPTokens()` if they called the `upgradeMultiplierLevel()` recently.

But for those users who dont call `upgradeMultiplierLevel()` recently, they still can use `deposit()` or `withdrawLPTokens()` functions.

#### Alleviation:

The BASE team confirmed this is designed intentionally to push users to migrate their tokens to CascadeV2.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-08" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-08: Logic issue in `withdrawLPTokens()`

| Type | Severity | Location |
| ------------- | -------- | ----------------------- |
| Volatile Code | Major | [CascadeV2.sol L105](#) |

#### Description:

1.L190, in function `withdrawLPTokens()` , `i++` should be `i--`.

 for (uint256 i = userDeposits_numLPTokens[msg.sender].length - 1; i >= 0; i++) {

2.L192, variables `lpTokens` and `totalAmountToWithdraw` were never initialized before usage.

 for (uint256 i = userDepositsNumLPTokens[msg.sender].length - 1; i >= 0; i++) {
            uint256 lpTokens;
            if (totalAmountToWithdraw.add(lpTokens) < amount) {
                lpTokens = userDepositsNumLPTokens[msg.sender][i];
                userDepositsNumLPTokens[msg.sender].pop();
                userDepositsDepositTimestamp[msg.sender].pop();
            } else {

Hence the first round of the for loop is meaningless, since `totalAmountToWithdraw.add(lpTokens)` equals to `0+0`.
3.L202, `userDepositsDepositTimestamp[msg.sender][i]` is already poped. Addtionllay, the timestamp is not the age.

 uint256 age = userDepositsDepositTimestamp[msg.sender][i];

#### Recommendation:

We recommend to change the code as below:
1.

 for (uint256 i = userDeposits_numLPTokens[msg.sender].length - 1; i >= 0; i--) {

2.

  for (uint256 i = userDepositsNumLPTokens[msg.sender].length - 1; i >= 0; i++) {
            uint256 lpTokens = userDepositsNumLPTokens[msg.sender][i];
            if (totalAmountToWithdraw.add(lpTokens) < amount) {
                userDepositsNumLPTokens[msg.sender].pop();
                userDepositsDepositTimestamp[msg.sender].pop();
            } else {

3.

 uint256 age = now.sub(userDepositsDepositTimestamp[msg.sender][i-1]);

#### Alleviation:

The team heeded our advice and fixed the logical issue in this Exhibit.
The recommendations were applied in commit 4c029e72ce6ef69888bd5850ef7066eb96e62cdd.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-09" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-09: Code Redundancy and Inefficiency

| Type | Severity | Location |
| --------- | ------------- | ----------------------- |
| Dead Code | Informational | [CascadeV2.sol L235](#) |

#### Description:

Unused state variable.

L235     uint256 depositSecondsToBurn;
L449     uint256 shares;

Missing control logic in function `removeDepositSeconds` to stop the loop once the amount is enough.

L220     for (uint256 i = userDepositsNumLPTokens[msg.sender].length; i > 0; i--) {
				...}

#### Recommendation:

We recommend to remove unused state variables and adding control logic in function `removeDepositSeconds` to stop the loop once the amount is enough.
Otherwise the function will loop the whole `userDepositsNumLPTokens[msg.sender]` array.

L249       totalAmountToWithdraw = totalAmountToWithdraw.add(lpTokensToRemove);
L250       if(totalAmountToWithdraw == numLPTokens) break;

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### <a name="UNP-10" style="display:none"> </a><img src="https://svgshare.com/i/Pp1.svg" width="40"/> CAS-10: Potential Underflow

| Type | Severity | Location |
| ----------------------- | ------------- | ---------------------------- |
| Mathematical Operations | Informational | [CascadeV2.sol L243,L247](#) |

#### Description:

Below codes did not use SafeMath for subtraction. It is possible to lead to underflow.

L243         totalDepositSecondsToBurn = totalDepositSecondsToBurn.add(lpTokensToRemove.mul(30 days + (age - 30 days).mul(2)));
L247         totalDepositSecondsToBurn = totalDepositSecondsToBurn.add(lpTokensToRemove.mul(30 days + uint256(30 days).mul(2) + (age - 60 days).mul(3)));  

#### Recommendation:

We recommend to use SafeMath for calculations.

<div style="page-break-after: always; visibility: hidden">
\pagebreak
</div>

### **Appendix**

------

### **Finding Categories**

**Gas Optimization**

Gas Optimization findings refer to exhibits that do not affect the functionality of the code but generate different, more optimal EVM opcodes resulting in a reduction on the total gas cost of a transaction.

**Mathematical Operations**

Mathematical Operation exhibits entail findings that relate to mishandling of math formulas, such as overflows, incorrect operations etc.

**Logical Issue**

Logical Issue findings are exhibits that detail a fault in the logic of the linked code, such as an incorrect notion on how `block.timestamp` works.

**Control Flow**

Control Flow findings concern the access control imposed on functions, such as owner-only functions being invoke-able by anyone under certain circumstances.

**Volatile Code**

Volatile Code findings refer to segments of code that behave unexpectedly on certain edge cases that may result in a vulnerability.

**Data Flow**

Data Flow findings describe faults in the way data is handled at rest and in memory, such as the result of a `struct` assignment operation affecting an in-memory `struct` rather than an instorage one.

**Language Specific**

Language Specific findings are issues that would only arise within Solidity, i.e. incorrect usage of `private` or `delete` .

**Coding Style**

Coding Style findings usually do not affect the generated byte-code and comment on how to make the codebase more legible and as a result easily maintainable.

**Inconsistency**

Inconsistency findings refer to functions that should seemingly behave similarly yet contain different code, such as a `constructor` assignment imposing different `require` statements on the input variables than a setter function.

**Magic Numbers**

Magic Number findings refer to numeric literals that are expressed in the codebase in their raw format and should otherwise be specified as `constant` contract variables aiding in their legibility and maintainability.

**Compiler Error**

Compiler Error findings refer to an error in the structure of the code that renders it impossible to compile using the specified version of the project.

**Dead Code**

Code that otherwise does not affect the functionality of the codebase and can be safely omitted.

------

### **Icons explanation**

&nbsp;<img src="https://s3.ax1x.com/2021/01/06/sEGTsI.png" style="zoom:4%;" /> : Issue resolved

&nbsp;<img src="https://s3.ax1x.com/2021/01/06/sEYm4S.png" style="zoom:3.8%;" /> : Issue not resolved / Acknowledged. The team will be fixing the issues in the own timeframe.

<img src="https://s3.ax1x.com/2021/01/06/sE8IbV.png" style="zoom:5.2%;" /> : Issue partially resolved. Not all instances of an issue was resolved.