# Findings

### **Issue 01**

| **Type**      | **Severity** | **Location** | Status |
| ------------- | ------------ | ------------ | ------ |
| Best Practice | Medium       | `receive`    | Fixed  |

**Description**

In order to prevent the contract from receiving ETH from investors, which will be resulted in a loss of funds.

```
	receive() external payable {}
```

**Recommendation**

Our recommendation is to have “whitelisted” addresses which can send ETH to the contract (for example the router address should be whitelisted).

When an investor sends ETH by mistake, the transaction will be reverted by the contract.

### **Issue 02**

| **Type**      | **Severity**  | **Location**                                                                                                                                | Status |
| ------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| Best Practice | Informational | <p><code>setWhiteLists</code> ,<code>removeWhiteLists</code> ,<code>setAddressForBosses,</code> <code>sweepTokenForBosses</code></p><p></p> | Fixed  |

**Description**

Lack of events in the contract.

**Recommendation**

Our recommendation is to emit events when changing the contract state.

### **Issue 03**

| **Type**           | Severity | Location           | Status |
| ------------------ | -------- | ------------------ | ------ |
| Owner Capabilities | High     | `setRouterAddress` | Fixed  |

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

**Recommendation**

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.