Froggy security record

In the contract `Froggy` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. - `claimStuckTokens`: withdraw the contract's eth and tokens - `setBuyTax`: update buy fee `marketingTaxBuy` - `setSellTax`: update sell fee `marketingTaxSell` - `setTransferTax`: update transfer fee `marketingTaxTransfer` - `setMarketingWallet`: update the marketing wallet `marketingWallet` - `setSwapTokensAtAmount`: update `swapTokensAtAmount` - `toggleSwapBack`: update `isSwapBackEnabled` - `setAutomatedMarketMakerPair`: update `_isAutomatedMarketMakerPair` - `setExcludeFromFees`: update `_isExcludedFromFees`  In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and transfer/renounce the ownership of the contract. 

All of the `FROGGY` tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The `Froggy` contract has a whitelist used for excluding some addresses from the fees mechanism. For example, ```solidity _isExcludedFromFees[address(this)] = true; _isExcludedFromFees[address(uniswapV2Router)] = true; _isExcludedFromFees[address(owner())] = true; _isExcludedFromFees[address(0xdead)] = true; ``` However, the address of the **Liquidity Pool Pair** is not whitelisted from the fees. Therefore, it might lead to an **unbalanced** liquidity pool.

A sandwich attack may 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 (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) 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: - `swapExactTokensForTokensSupportingFeeOnTransferTokens()`

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=864 IUniswapV2Router02 public immutable uniswapV2Router; ``` - The contract `Froggy` interacts with third party contract with `IUniswapV2Router02` interface via `uniswapV2Router`.

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=941 payable(msg.sender).transfer(address(this).balance); ``` - `Froggy.claimStuckTokens` uses `transfer()`.