# Findings

## **Issue 01**

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

**Description**

The contract contains a minter role. Anyone with that role can mint as many tokens as they would like.

**Recommendation**

Remove this function.

## **Issue 02**

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

**Description**

The token is pausable which means, critical functions such as transfer can be paused by the Pauser role.

**Recommendation**

Protect the contract by adding a timelock that delays the actual execution of the pause function..

## **Issue 03**

| **Type**           | **Severity**                                        | **Location**          | **Status**                                        |
| ------------------ | --------------------------------------------------- | --------------------- | ------------------------------------------------- |
| Owner Capabilities | <mark style="color:green;">**Informational**</mark> | `addBlacklistAddress` | ✔️ <mark style="color:green;">**Resolved**</mark> |

**Description**

This function is not needed as its job is covered by the BotProtection

**Recommendation**

Remove this function.

## **Issue 04**

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

**Description**

`approve` is being called every transaction on the same tokens and for the same spender (the router).&#x20;

**Recommendation**

In order to reduce gas cost, `approve` could be called once (with max int), and then check if it is needed again using `allowance`

## **Issue 05**

| **Type**      | **Severity**                                        | **Location**       | **Status**                                        |
| ------------- | --------------------------------------------------- | ------------------ | ------------------------------------------------- |
| Best Practice | <mark style="color:green;">**Informational**</mark> | `swapTokensForBNB` | ✔️ <mark style="color:green;">**Resolved**</mark> |

**Description**

It is considered best practice to always gracefully handle external calls as they might fail.

**Recommendation**

Wrap external contract calls (e.g. `swapExactTokensForETHSupportingFeeOnTransferTokens`)

with try-catch.

## **Issue 06**

| **Type**           | **Severity**                                  | **Location**              | **Status**                                        |
| ------------------ | --------------------------------------------- | ------------------------- | ------------------------------------------------- |
| Owner Capabilities | <mark style="color:orange;">**Medium**</mark> | `initializePancakeRouter` | ✔️ <mark style="color:green;">**Resolved**</mark> |

**Description**

The owner can set PancakeSwap's router address, which gives him full control over all token swaps.

**Description**

Consider implementing a timelock mechanism to allow users to review the changes, or remove this feature altogether as backward-incompatible router updates are a very rare event.&#x20;