# Findings

## **Issue 0**1

| **Type**      | **Severity**                                  | **Location** | **Status**                                     |
| ------------- | --------------------------------------------- | ------------ | ---------------------------------------------- |
| Best Practice | <mark style="color:orange;">**Medium**</mark> | `contract`   | <mark style="color:green;">**Resolved**</mark> |

**Description**

Proxy contracts are very vulnerable and may easily cause high severity logical and security issues by misusing them.

**Recommendation**

Make sure you are familiar with the potential risks of using proxy contracts and have handled them properly.

## **Issue 02**

| **Type**           | **Severity**                             | **Location** | **Status**                                     |
| ------------------ | ---------------------------------------- | ------------ | ---------------------------------------------- |
| Owner Capabilities | <mark style="color:red;">**High**</mark> | `contract`   | <mark style="color:green;">**Resolved**</mark> |

**Description**

The contract is upgradeable which means the owner is able to change critical logic and behavior after the contract is deployed.

## Issue 03

| Type             | Severity                                   | Location           | Status                                         |
| ---------------- | ------------------------------------------ | ------------------ | ---------------------------------------------- |
| Gas Optimization | <mark style="color:yellow;">**Low**</mark> | `swapTokensForEth` | <mark style="color:green;">**Resolved**</mark> |

**Description**

`approve` is being called on every transaction which automatically contributes liquidity to the pool, on the same tokens and for the same spender (the router).

**Recommendation**

In order to reduce gas costs, `approve` could be called once (with max int).

## Issue 04

| Type          | Severity                                 | Location                         | Status                                         |
| ------------- | ---------------------------------------- | -------------------------------- | ---------------------------------------------- |
| Best Practice | <mark style="color:red;">**High**</mark> | `addLiquidity, swapTokensForEth` | <mark style="color:green;">**Resolved**</mark> |

**Description**

`_transfer` may internally call to `swapExactTokensForETHSupportingFeeOnTransferTokens` and  `addLiquidityETH`. Both of which may cause `_transfer` to fail unnecessarily.

**Recommendation**

`_transfer` should always work, and shouldn't fail if `swapExactTokensForETHSupportingFeeOnTransferTokens` or any other router-related functions fail, in order to make sure the **token will always be tradable.**

Use try-catch when calling external functions in critical path flows.&#x20;

Although it's a best practice to handle errors in a graceful manner, the likelihood of these functions failing constantly is low. &#x20;

## Issue 05

| Type          | Severity                                   | Location           | Status                                         |
| ------------- | ------------------------------------------ | ------------------ | ---------------------------------------------- |
| Logical Issue | <mark style="color:yellow;">**Low**</mark> | `_transferWithFee` | <mark style="color:green;">**Resolved**</mark> |

**Description**

The code does not emit events when transferring fees. This can cause blockchain explorers and DApps to inaccurately parse transfers and transactions.

**Recommendation**

Add Transfer event when taking fees.

## Issue 06

<table><thead><tr><th width="198">Type</th><th>Severity</th><th>Location</th><th>Status</th></tr></thead><tbody><tr><td>Owner Capabilities</td><td><mark style="color:red;"><strong>High</strong></mark></td><td><code>setLiquidityFee, setMarketingFee, setStakingFee</code></td><td><mark style="color:green;"><strong>Resolved</strong></mark></td></tr></tbody></table>

**Description**

There is no upper limit to the setFees functions. If the owner sets them to 100% the token will be untradeable.

**Recommendation**

Consider adding an upper limit to the set functions.

Furthermore, consider emitting events when changing the state of the contract, such as setting fees.

## Issue 07

<table><thead><tr><th width="198">Type</th><th>Severity</th><th>Location</th><th>Status</th></tr></thead><tbody><tr><td>Owner Capabilities</td><td><mark style="color:red;"><strong>High</strong></mark></td><td><code>pause</code></td><td><mark style="color:green;"><strong>Resolved</strong></mark></td></tr></tbody></table>

**Description**

The owner can pause the token and all transfer/allowance functions at any time.

**Recommendation**

Remove this function if not needed.