> For the complete documentation index, see [llms.txt](https://audits.solidgrp.io/footballgo/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://audits.solidgrp.io/footballgo/audit-results/findings.md).

# 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.