# Findings

### Issue 01

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

**Description**

The owner of the contract can set the buy rate to any value he desires. If the owner sets the fee to 100% the token will be untradeable.

**Recommendation**

Consider adding an upper limit to the set functions. In addition, consider lowering the upper limit from 20%.

**The owner added a 20% upper limit for buy transactions.**&#x20;

### Issue 02

|               |                                      |              |                                            |
| ------------- | ------------------------------------ | ------------ | ------------------------------------------ |
| **Type**      | **Severity**                         | **Location** | **Status**                                 |
| Logical Issue | <mark style="color:red;">High</mark> | \*           | <mark style="color:green;">Resolved</mark> |

**Description**

In the case where p2eReward > p2eAmount (the last reward mint), line XXX has a logical error that can mint more tokens than p2eAmount, instead of the desired behavior of minting up to p2eAmount.

**Recommendation**

Change the availableReward calculation to

uint256 availableReward = p2eAmount.sub(p2eReward.sub(reward));

which will mint the reaming tokens

### Issue 03

|               |                                      |              |                                            |
| ------------- | ------------------------------------ | ------------ | ------------------------------------------ |
| **Type**      | **Severity**                         | **Location** | **Status**                                 |
| Volatile Code | <mark style="color:red;">High</mark> | \_transfer   | <mark style="color:green;">Resolved</mark> |

**Description**

`_transfer` may call internally to `swapExactTokensForETHSupportingFeeOnTransferTokens` ,`addLiquidityETH`and `swapExactETHForTokensSupportingFeeOnTransferTokens` Since this function can be called during `_transfer`, it may cause `_transfer` to fail unnecessarily.

**Recommendation**

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

### Issue 04

|               |                                           |              |                                            |
| ------------- | ----------------------------------------- | ------------ | ------------------------------------------ |
| **Type**      | **Severity**                              | **Location** | **Status**                                 |
| Best Practice | <mark style="color:orange;">Medium</mark> | receive      | <mark style="color:red;">Unresolved</mark> |

**Description**

There is a receive function in the contract, which means any address can send BNB to the contract. The problem is that there is no way to recover BNB that were mistakenly sent to the contract.

**Recommendation**

In order to prevent the contract from receiving BNB from investors, which will result in a loss of funds, our recommendation is to only accept ETH from “whitelisted” addresses (for example the router address should be whitelisted). The receive function will revert if the address is not whitelisted.

### Issue 05

|               |                                           |              |                                            |
| ------------- | ----------------------------------------- | ------------ | ------------------------------------------ |
| **Type**      | **Severity**                              | **Location** | **Status**                                 |
| Logical Issue | <mark style="color:orange;">Medium</mark> | \_transfer   | <mark style="color:green;">Resolved</mark> |

**Description**

at the moment swap tokens for ETH only occur when the contract has at least 1% of the total supply, selling 1% of the total supply for ETH may cause a significant price impact.&#x20;

**Recommendation**&#x20;

Our recommendation is to lower the minimum value swap tokens for ETH occurs in order to prevent undesired dump.&#x20;

### Issue 06

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

**Description**

Approve is called only once in the constructor. This means the allowance of the contract to the router will decrease over time. This can lead to a scenario where swapExactTokensForETH will fail and no way to fix it.

**Recommendation**&#x20;

Our recommendation is to add an approve function that will give allowance to pancakeswap rouer to spend on behalf of the contract.

### **General Note**&#x20;

The gas consumption of the contract can be improved by changing the access permission of public functions which is not being called in the contract to external.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://audits.solidgrp.io/footballgo/audit-results/findings.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.