Baby Bonk security record

If `maxWalletLimitEnabled` is true and the wallet (`from`) in the `_isExcludedFromMaxWalletLimit` array transfers `maxWalletAmount + 1` tokens to a normal `to` wallet, the following check will pass. Consequently, the `to` wallet ends up holding a token amount that exceeds the maximum wallet limit. ```solidity=710 if (!_isExcludedFromMaxWalletLimit[from] && !_isExcludedFromMaxWalletLimit[to] && to != uniswapV2Pair ) { ```

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 contract is serving as the underlying entity to interact with third-party `UniswapV2` protocols. The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

```solidity=635 require(tradingEnabled || _isExcludedFromFees[from] || _isExcludedFromFees[to], "Trading not yet enabled!"); ``` Addresses in the `_isExcludedFromFees` array can engage in trading even when `tradingEnabled` is disabled. This is confusing, considering that the array name implies it is meant to be excluded from all fees.

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.