Security Assessment

DeFi Exchange - Audit

TechRight Verified on Mar 20th, 2023

## Table of contents - [Disclaimer](#t-disclaimer) - [Description](#t-description) - [Vulnerability & Risk Level](#t-vulnerability) - [Auditing Strategy and Techniques](#t-auditing-strategy) - [Tested Contract Files](#t-tested-contract) - [Scope](#t-scope) - [Source Units in Scope](#t-source-Units-in-Scope) - [Out of Scope](#t-out-of-scope) - [Excluded Source Units](#t-out-of-scope-excluded-source-units) - [Duplicate Source Units](#t-out-of-scope-duplicate-source-units) - [Doppelganger Contracts](#t-out-of-scope-doppelganger-contracts) - [Report Overview](#t-report) - [Risk Summary](#t-risk) - [Source Lines](#t-source-lines) - [Inline Documentation](#t-inline-documentation) - [Components](#t-components) - [Exposed Functions](#t-exposed-functions) - [StateVariables](#t-statevariables) - [Capabilities](#t-capabilities) - [Dependencies](#t-package-imports) - [Totals](#t-totals) - [Detectors Issue](#t-detectors)

## Disclaimer

TechRight.io Reports do not constitute an endorsement or disapproval of any specific project or team, and they should not be taken as an indication of the economic value of any product or asset created by a team. Additionally, TechRight.io does not perform testing or auditing of integration with external contracts or services like Unicrypt, Uniswap, PancakeSwap, and others.

TechRight.io Audits do not offer any assurance or pledge about the complete absence of bugs in the evaluated technology, and they do not give any hint about the owners of the technology. These audits should not be relied upon to make any investment or participation decisions in any specific project, nor should they be used as any form of investment advice.

TechRight.io Reports involve a comprehensive auditing process to support our clients in enhancing their code quality while reducing the risk associated with blockchain technology and cryptographic assets. Please note that every company and individual is responsible for conducting their own due diligence and maintaining continuous security. Please note that TechRight does not guarantee the security or functionality of the technology we confirm to evaluate.

## Description

Network

Binance Smart Chain (BEP20)

## Vulnerability & Risk Level

Risk represents the probability that a certain source-threat will exploit vulnerability, and the impact of that event on the organization or system. Risk Level is computed based on CVSS version 3.0

| Level | Value | Vulnerability | Risk
(Required Action) | | ------------- | ----------- | ------------ | ---------- | | Critical | 9 - 10 | A vulnerability that can disrupt the contract functioning in a number of scenarios, or creates a risk that the contract may be broken. | Immediate action to reduce risk level. | | High | 7 - 8.9 | A vulnerability that affects the desired outcome when using a contract, or provides the opportunity to use a contract in an unintended way. | Implementation of corrective actions as soon as possible. | | Medium | 4 - 6.9 | A vulnerability that could affect the desired outcome of executing the contract in a specific scenario. | Implementation of corrective actions in a certain period. | | Low | 2 - 3.9 | A vulnerability that does not have a significant impact on possible scenarios for the use of the contract and is probably subjective. | Implementation of certain corrective actions or accepting the risk. | | Informational | 0 - 1.9 | A vulnerability that has informational character but is not affecting any of the code.|An observation that does not determine a level of risk |

## Auditing Strategy and Techniques Applied

During the evaluation process, the repository was thoroughly examined to identify any security-related concerns, assess code quality, and ensure adherence to specifications and best practices. Our team of expert pentesters and smart contract developers reviewed the code line-by-line and documented any issues identified.

Methodology

The auditing process follows a step-by-step routine:

1. Code review that includes:
i. Review of the specifications, sources and instructions provided to TechRight to ensure a thorough understanding of the size, scope, and functionality of the smart contract's. ii. Manual review of code, which involves carefully reading the source code line-by-line to identify potential vulnerabilities. iii. Comparison to specification, which is the process of confirming whether the code performs as described in the specifications, sources, and instructions provided. 2. Testing and automated analysis that includes the following:
i. Test coverage analysis, which involves assessing the degree to which test cases cover the code and how much of the code is executed while running those test cases. ii. Symbolic execution, which refers to the analysis of a program to identify the inputs that trigger each component of the program to execute. 3. Best practices review, which involves evaluating smart contracts to enhance efficiency, effectiveness, clarity, maintainability, security, and control in accordance with industry and academic practices, recommendations, and research. 4. Specific, itemized, actionable recommendations that enable you to take necessary measures to secure your smart contracts.

## Tested Contract Files

This audit covered the following files listed below with a SHA-1 Hash.

A file with a different Hash has been modified, intentionally or otherwise, after the security review. A different Hash could be (but not necessarily) an indication of a changed condition or potential vulnerability that was not within the scope of this review

## Scope This section lists files that are in scope for the metrics report. - **Project:** `'CLI'` - **Included Files:** - `` - **Excluded Paths:** - `` - **File Limit:** `undefined` - **Exclude File list Limit:** `undefined` - **Workspace Repository:** `unknown` (`undefined`@`undefined`) ### Source Units in Scope Source Units Analyzed: **`1`**
Source Units in Scope: **`1`** (**100%**) | Type | File | Logic Contracts | Interfaces | Lines | nLines | nSLOC | Comment Lines | Complex. Score | Capabilities | | ---- | ------ | --------------- | ---------- | ----- | ------ | ----- | ------------- | -------------- | ------------ | | 📝 | /Users/hohoai/Desktop/nextjs/tech-right-tool/src/TestToken.sol | 1 | **** | 44 | 44 | 36 | 1 | 27 | **** | | 📝 | **Totals** | **1** | **** | **44** | **44** | **36** | **1** | **27** | **** | _{Legend:

Lines: total lines of the source unit
nLines: normalized lines of the source unit (e.g. normalizes functions spanning multiple lines)
nSLOC: normalized source lines of code (only source-code lines; no comments, no blank lines)
Comment Lines: lines containing single or block comments
Complexity Score: a custom complexity score derived from code statements that are known to introduce code complexity (branches, loops, calls, external interfaces, ...)} #### Out of Scope ##### Excluded Source Units Source Units Excluded: **`0`**

| File | | ------ | | None |

##### Duplicate Source Units Duplicate Source Units Excluded: **`0`**

| File | | ------ | | None |

##### Doppelganger Contracts Doppelganger Contracts: **`0`**

| File | Contract | Doppelganger | | ------ | -------- | ------------ |

## Report ### Overview The analysis finished with **`0`** errors and **`0`** duplicate files. #### Risk

#### Source Lines (sloc vs. nsloc)

#### Inline Documentation - **Comment-to-Source Ratio:** On average there are`36` code lines per comment (lower=better). - **ToDo's:** `undefined` #### Components | 📝Contracts | 📚Libraries | 🔍Interfaces | 🎨Abstract | | ------------- | ----------- | ------------ | ---------- | | 1 | 0 | 0 | 0 | #### Exposed Functions This section lists functions that are explicitly declared public or payable. Please note that getter methods for public stateVars are not included. | 🌐Public | 💰Payable | | ---------- | --------- | | 8 | 0 | | External | Internal | Private | Pure | View | | ---------- | -------- | ------- | ---- | ---- | | 0 | 1 | 0 | 5 | 2 | #### StateVariables | Total | 🌐Public | | ---------- | --------- | | 2 | 0 | #### Capabilities | Solidity Versions observed | 🧪 Experimental Features | 💰 Can Receive Funds | 🖥 Uses Assembly | 💣 Has Destroyable Contracts | | -------------------------- | ------------------------ | -------------------- | ---------------- | ---------------------------- | | `^0.8.9` | | **** | **** | **** | | 📤 Transfers ETH | ⚡ Low-Level Calls | 👥 DelegateCall | 🧮 Uses Hash Functions | 🔖 ECRecover | 🌀 New/Create/Create2 | | ---------------- | ----------------- | --------------- | ---------------------- | ------------ | --------------------- | | **** | **** | **** | **** | **** | **** | | ♻️ TryCatch | Σ Unchecked | | ---------- | ----------- | | **** | **** | #### Dependencies / External Imports | Dependency / Import Path | Count | | ------------------------ | ------ | #### Totals ##### Summary

##### AST Node Statistics ###### Function Calls

###### Assembly Calls

###### AST Total

##### Inheritance Graph

##### CallGraph

###### Contract Summary

Sūrya's Description Report Files Description Table | File Name | SHA-1 Hash | |-------------|--------------| | /Users/hohoai/Desktop/nextjs/tech-right-tool/src/TestToken.sol | ac25f9cc96082e757dc6afaa5e9fbb7377914d52 | Contracts Description Table | Contract | Type | Bases | | | |:----------:|:-------------------:|:----------------:|:----------------:|:---------------:| | └ | **Function Name** | **Visibility** | **Mutability** | **Modifiers** | |||||| | **Exceptions** | Implementation | ||| | └ | assert1 | Public ❗️ | |NO❗️ | | └ | counter_increase | Public ❗️ | 🛑 |NO❗️ | | └ | assert5 | Public ❗️ | |NO❗️ | | └ | assert2 | Public ❗️ | |NO❗️ | | └ | assert3 | Public ❗️ | |NO❗️ | | └ | require_is_fine | Public ❗️ | |NO❗️ | | └ | this_is_fine | Public ❗️ | |NO❗️ | | └ | this_is_find_2 | Public ❗️ | |NO❗️ | Legend | Symbol | Meaning | |:--------:|-----------| | 🛑 | Function can modify state | | 💵 | Function is payable |

____ _{Thinking about smart contract security? We can provide training, ongoing advice, and smart contract auditing. [Contact us](https://diligence.consensys.net/contact/).}

## Detectors Issue | Description | Check | Impact | Confidence | | ------------- | ----------- | ------------ | ---------- | | Exceptions.myarray (TestToken.sol#6) is never initialized. It is used in:
- Exceptions.this_is_find_2(uint256) (TestToken.sol#38-42)
| uninitialized-state | High | High | | Pragma version^0.8.9 (TestToken.sol#2) allows old versions
| solc-version | Informational | High | | solc-0.8.19 is not recommended for deployment
| solc-version | Informational | High | | Function Exceptions.this_is_fine(uint256) (TestToken.sol#32-36) is not in mixedCase
| naming-convention | Informational | High | | Function Exceptions.this_is_find_2(uint256) (TestToken.sol#38-42) is not in mixedCase
| naming-convention | Informational | High | | Function Exceptions.require_is_fine(uint256) (TestToken.sol#28-30) is not in mixedCase
| naming-convention | Informational | High | | Parameter Exceptions.assert5(uint256).input_x (TestToken.sol#15) is not in mixedCase
| naming-convention | Informational | High | | Function Exceptions.counter_increase() (TestToken.sol#12-14) is not in mixedCase
| naming-convention | Informational | High |;

Background Header