PEPEF

There should always be events emitted in the sensitive functions that are controlled by centralization roles. Specifically: - `enableTrading()` does not emit an event when is executed. - `claimStuckTokens()` emits an event only when `ERC20token.transfer()` is executed. No event is emitted when BNB is withdrawn from the contract.

When the contract is deployed the following addresses are exempted from fees: - the current `owner` - the current `marketingWallet` If ownership is transferred or renounced with `transferOwnership()` or `renounceOwnership()`, the exemptions are not granted to the new owner nor are they revoked from the previous owner. Also if `marketingWallet` is updated with `changeMarketingWallet()` the exemptions are not granted to the new marketing wallet nor are they revoked from the previous marketing address.

State variables that never change should be declared as `constant` to save gas. ```solidity=549 string public creator; ``` - `creator` should be declared `constant`.

The return values of the `transfer()` and `transferFrom()` calls in the smart contract are not checked. Some ERC-20 tokens' transfer functions return no values, while others return a bool value, they should be handled with care. If a function returns `false` instead of reverting upon failure, an unchecked failed transfer could be mistakenly considered successful in the contract. ```solidity=617 ERC20token.transfer(msg.sender, balance); ```

```solidity=20 interface IUniswapV2Pair { ``` - `IUniswapV2Pair` is declared but never used.

The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. ```solidity=612 payable(msg.sender).sendValue(address(this).balance); ``` --- ```solidity=714 payable(marketingWallet).sendValue(newBalance); ```

The linked magic numbers are hardcoded in the codebase.

- `address public uniswapV2Pair;` - `uint256 public marketingFeeOnBuy;` - `uint256 public marketingFeeOnSell;` - `address public marketingWallet;` The above 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.