Baby Doge security record

In the contract TreasuryFeeManager.sol at the address of [0x1B6878aDfB16B949a8ceF2fB28228AFC84FCb6a8](https://bscscan.com/address/0x1B6878aDfB16B949a8ceF2fB28228AFC84FCb6a8), the role `MANAGER_ROLE` has authority over the following functions: - `addLP()` - `replaceLP()` - `unwrapTokens()` Any compromise to the `MANAGER_ROLE` account may allow a hacker to take advantage of this authority and execute sensitive functions and update the sensitive settings of the project.

In the contract, `BabyDogeV2Factory`, the role, `feeToSetter`, has authority over the functions shown in the diagram below.  --- In the contract, `BabyDogeV2Pair`, the role, `factory`, has authority over the functions shown in the diagram below.  In the contract, `BabyDogeV2Pair`, the role, `router`, has authority over the functions shown in the diagram below.  --- In the contract, `BabyDogeV2Router02`, the role, `WETH`, has authority over the functions shown in the diagram below.  In the contract, `BabyDogeV2Router02`, the role, `feeSetter`, has authority over the functions shown in the diagram below.  --- In the contract, `SmartChefInitializable`, the role, `SMART_CHEF_FACTORY`, has authority over the functions shown in the diagram below.  Moreover, the role,`GOVERNANCE_ROLE`, in the contract `SmartChefInitializable` has authority over the following functions: - `emergencyRewardWithdraw()` - `recoverWrongTokens()` - `stopReward()` - `updatePoolLimitPerUser()` - `updateRewardPerBlock()` - `updateStartAndEndBlocks()` --- In the contract, `dexFeeManager`, the role,`GOVERNANCE_ROLE`, in the contract `SmartChefInitializable` has authority over the following functions: - `addLP()` - `setAllocationSettings()` - `setTreasuryAddress()` - `setBuybackTokens()` - `replaceLP()` - `swaptoBuyBack()` - `sendBuyBackToBurnWallet()` - `withdrawETH()` - `withdrawERC20()` --- Any compromise to the privileged account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. However, by the structure of the function and if the `feeReceiver` is set by the owner then there is a low risk of such an attack.

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

When users add or remove LP tokens into the router, and the `mint` and `burn` operations are performed. When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, the amount inconsistency will occur and the transaction may fail due to the validation checks.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - `swapExactTokensForTokens()` - `swapExactTokensForTokensSupportingFeeOnTransferTokens()`

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

The usage of `allPairs` array is as a counter to maintain the number of created pairs.