> For the complete documentation index, see [llms.txt](https://audits.solidgrp.io/burning-moon-audit/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/burning-moon-audit/findings.md).
# Findings
### **Issue 01**
| **Type** | Severity | Location | Status |
| ---------------- | ------------- | ---------- | ------ |
| Gas Optimization | Informational | `fallback` | Fixed |
**Description**
The fallback function seems to be redundant.
### **Issue 02**
| **T**ype | Severity | Location | Status |
| ------------- | -------- | ------------- | ------ |
| Best Practice | Low | `addLiquidty` | Fixed |
**Description**
`addLiquidity` calls the external function `addLiquidityETH` . Since this function can be called during `_transfer`, it may cause `_transfer` to fail unnecessarily.
**Recommendation**
Use try-catch when calling external functions in critical path flows. Our recommendation is to Always make sure error cases are handled gracefully in critical functions such as `_transfer`
### **Issue 03**
| **Type** | Severity | Location | Status |
| ---------------- | ------------- | ---------------- | ----------- |
| Gas Optimization | Informational | `swapAndLiquify` | Acknowledge |
**Description**
Your current code doesn’t **differentiate** between **sell transaction and addLiquidity transaction** (because the user sends tokens to the pair) and **buy transaction and removeLiquidity** transaction (because the user receives tokens from the pair). Therefore, balanceLimit and custom tax will be applied to liquidity removal and liquidity addition as well.
### Issue 04
| **Type** | Severity | Location | Status |
| ---------------- | ------------- | ---------------- | ------ |
| Gas Optimization | Informational | `swapAndLiquify` | Fixed |
The owner of the contract can set the lock time between two consecutive sells. Since the contract is constantly selling tokens for BNB as part of the staking rewards and AMM mechanism, If the token contract won’t be excluded from this limitation the contract could only sell once every 2 hours. If swapAndLiquify will take place on every sell transaction the sell transactions will constantly fail.
**Recommendation**
Our recommendation is to use try, catch when calling external functions and to make sure the contract can’t be excluded for sell cooldown limitations.
### Issue 05
| **Type** | Severity | Location | Status |
| ------------- | ------------- | ------------------------------------------------ | ------ |
| Best Practice | Informational | TeamSetPromotionToken
| Fixed |
**Description**
This function changes the state of the contact by setting critical operational variables.
**Recommendation**
Our recommendation is to emit event when changing critical variables or when the state of the contract changed.
### Issue 06
| **Type** | Severity | Location | Status |
| ------------- | ------------- | -------------------------------------------------- | ------ |
| Logical Issue | Informational | promotionStartTimestamp
| Fixed |
**Description**
The variable `promotionStartTimestamp` is not used in the contract. When the team sets the promotion token by calling `TeamSetPromotionToken` it takes place immediately, instead of being delyaed by `promotionStartTimestamp`
**Recommendation**
Our recommendation is to delete this variable, or to implement the delay logic in the code.
### Issue 07
| **Type** | Severity | Location | Status |
| ------------- | ------------- | ---------------------------------------------- | ------ |
| Logical Issue | Informational | \_buyLotteryTickets
| Fixed |
**Description**
According to the comments, `lotteryTicketPrice`is supposed to be 100 tokens, however, it is set to 1000 tokens.
```
uint256 public lotteryTicketPrice=1000*(10**_decimals); //StartPrize Lottery 100 token
```
### Issue 08
| **Type** | Severity | Location | Status |
| ------------- | -------- | ---------------------------------------------- | ------ |
| Volatile Code | Medium | \_buyLotteryTickets
| Fixed |
**Description**
Each user can buy any number of lottery tickets. This function iterates over the number of tickets the user purchased. Iterating over an unbounded array can hit the block gas limit.
**Recommendation**
Our recommendation is to limit the number of tickets a user can purchase.
### **Issue 09**
| Type | Severity | Location | Status |
| ---------------- | ------------- | ---------- | ------ |
| Gas Optimization | Informational | `_approve` | Fixed |
approve is being called every transaction 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), and then check if it is needed again using `allowance`.
### **Issue 10**
| Type | Severity | Location | Status |
| ------------- | -------- | -------------------- | ----------- |
| Volatile Code | Low | `_swapContractToken` | Acknowledge |
**Description**
The team set the number of tokens to be swapped to 5% of the pair's token balance. 5% of the pair balance will result in more than 5% price impact on the token's price.
**Recommendation**
Consider lowering the number of tokens to be swapped or to set `sellLimit` in order to prevent a major price impact.
### Issue 11
| Type | Severity | Location | Status |
| ------------------ | -------- | ------------------------ | ----------- |
| Owner Capabilities | Medium | `TeamRemoveRemainingBNB` | Acknowledge |
**Description**
Every 7 days the team has the ability to withdraw all the bnbs from the contract. The contract holds the BNBs that were allocated for marketing and the BNBs that were allocated for staking rewards.
The team can withdraw the BNBs that were allocated for staking rewards.
**Recommendation**
Consider using a timelock contract in order to delay the execution of a function like that, or only enable to withdraw tokens who were allocated for marketing.