BaoBey

All `BeBe` tokens are sent to the `mint_wallet` address upon contract deployment. The `mint_wallet` address [`0x380F3734C32F0ef998955E5d57BA1E69f7a5DD4f`](https://bscscan.com/address/0x380f3734c32f0ef998955e5d57ba1e69f7a5dd4f) is an externally owned account, posing a potential centralization risk as the `mint_wallet` can distribute `BeBe` tokens without the consensus of the community.

Within the `_transfer()` function, the boolean variable `transfer_delay_enabled` being true can lead the function call to access a block of code that requires the user invoking the call to not have made a previous call within the same block. While the check does not apply if the `to` address is the `uniswapV2Router` or `uniswap_v2_pair`, there is no consideration of the `from` address being the `uniswapV2Router` or `uniswap_v2_pair` addresses, therefore potentially limiting swapping capabilities. There are instances in which the `from` address and the `_msgSender()` are either both `uniswapV2Router` or both `uniswap_v2_pair`; in those cases, the router or pair address will not be able to make such a call more than once in a block.

The `_transfer()` function implementation within the contract `BaoBeyToken` uses **require statements** to ensure that the `from` and `to` addresses passed as parameters are not `address(0)`. While these are important checks to have, the checks already exist in the `ERC20.sol` contract implementation of `_transfer()`, which is eventually called and used to handle the actual transfers. Therefore, the linked **require statements** are redundant and can be removed.

The comment in Line 726 says "devOrOwner", but the modifier used is called "marketingOrOwner".

The constructor of the `BaoBeyToken` contract is `payable`. The contract also includes a `payable` `receive()` function; however, there are no functions that allow the BNB to be withdrawn. Therefore, BNB used to create the contract and any other BNB sent to the contract will be locked.

There should always be events emitted in the sensitive functions that are controlled by centralization roles. The following functions are privileged functions controlled by the `owner` role and should emit events upon being called: - `init()` - `removeLimits()` - `disableTransferDelay()` - `setIsExcludedFromTax()` - `setAutomatedMarketMakerPair()` - `enableTrading()`

The variables `uniswap_v2_pair` and `_dead_wallet` are already of type `address` and are redundantly casted to that type.

State variables that never change should be declared as `constant` to save gas. ```solidity=616 uint256 private _gas_price_limit = 70 * 1 gwei; ``` - `_gas_price_limit` should be declared `constant`.

Upon contract deployment, the two boolean variables `limits_in_effect` and `_gas_limit_active` are initialized to `true`. The value of these variables can only be changed by calling the `removeLimits()` function, which changes both variables to `false` (at which point they can never be made `true` again). In the following lines of code from the `_transfer()` function, the checks can be optimized as they are redundant. ```solidity=658 if (limits_in_effect && trading_enabled) { if ( from != owner() && to != owner() && to != address(0) && to != address(0xdead) ) { if (_gas_limit_active && automated_market_maker_pairs[from]) { require( tx.gasprice <= _gas_price_limit, "_transfer: Gas price exceeds limit" ); } ``` Since the first check in Line 658 is checking whether or not `limits_in_effect` is true, the second check in Line 665 regarding `_gas_limit_active` is unnecessary since these two variables will always be consistently set. ---- Additionally, the check in Line 662 is unnecessary due to the following **require statement**: ```solidity=654 require(to != address(0), "ERC20: transfer to the zero address"); ``` Since the function will revert if the `to` address is the 0 address, there is no need to check this again in Line 662.

The `_transfer()` function contains a series of checks that evaluate the value of certain variables before executing blocks of code. At least seven boolean variables are considered within the call; therefore there are at least 128 (i.e., 2^7) possible cases that can be passed through the function. As a result, it is likely that not all test cases have been considered and the function may behave unexpectedly in certain cases.