FORTUNE

Assume the fees are all zero except for `marketingFeeOnBuy` and `marketingFeeOnSell` are `1` as they are in the `constructor()`. In this assume that the fees are gathered using these fees up until `canSwap` would be true and before there is a sell so that `swapAndSendMarketing()` has not been called. Then assume the buy and sell fees are updated so that all fees are zero except for `liquidityFeeOnBuy` and `liquidityFeeOnSell` which are set to 1. Then a sell is executed so that in this case it will `swapAndLiquify()` the entire `contractTokenBalance` as the `marketingShare` will be zero because of the updated fees. However, all those fees were generated to be swapped and sent to the marketing address instead of added to liquidity. In addition, the `walletToWalletTransferFee` is split between marketing and liquidity based on the buy and sell fees. This can cause confusion as to what percentage of a transfer is allocated for marketing versus liquidity.

The following functions are never called internally within the contract and should have external visibility: - `enableTrading()` - `isExcludedFromFees(address account)`

The function `excludeFromFees()` allows not only to exclude an address from fees but also allows to include an address paying fees.

The `swapAndLiquify()` function converts half of the `FORTUNEUM` tokens to `BNB`. The other half of `FORTUNEUM` tokens and part of the converted `BNB` tokens are then added as liquidity to the `uniswapV2Pair`. For every `swapAndLiquify()` function call, a small amount of `BNB` is left over in the contract. This is because the price of `FORTUNEUM` drops after swapping the first half into `BNB`, and the other half of `FORTUNEUM` require less than the converted `BNB` to be paired with when adding liquidity. The contract has a `claimStuckTokens()` function, which withdraws the contracts `BNB` balance to the `msg.sender`, so we mark this finding as **informational** as the tokens will not be locked forever.

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.

The contract uses the latest solidity version available at the moment which is `0.8.17`. Using the most recent version can be risky as all bugs for the current version may not be known.

The contract is serving as the underlying entity to interact with a third party AMM protocol. The scope of the audit treats third party entities as black boxes and assume 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.

The return value of the transfer() call is not checked. ```solidity=760 ERC20token.transfer(msg.sender, balance); ```

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