Father Of Meme: Origin security record

In the contract `FOMO` 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 set limit, set pair and router address, add/remove user from exempt fee list, enable/disable tax, enable/disable trade, change tax wallet address and change swap threshold. 

All of the FOMO tokens are sent to the contract deployer . This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to the deployer address may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The contract includes a `swapBack()` function designed to convert transaction fees collected in the form of FOMO tokens into the native token. The function calculates the `amountToSwap` based on the balance of FOMO tokens held by the contract itself. The logic then ensures that `amountToSwap` does not exceed predefined limits such as `swapTokensAtAmount` and `maxSwapTokens`. Critically, the function also adjusts `amountToSwap` to not exceed the amount passed to `swapBack()`, which is determined by user. A significant issue arises from the design choice to allow the swapBack() function to trigger on any transaction amount, even if minimal. This approach can lead to highly inefficient gas usage: the function will execute (including potentially expensive token swaps) even for small transaction amounts. This could disproportionately increase the transaction cost for users, as they will incur not only the gas fees for their transfer but also the additional costs associated with the token swap operation.

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. ```solidity= dexRouter.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, // accept any amount of ETH path, address(this), block.timestamp ); ``` Since the transaction fee of the token is relatively low(1%), the possibility of sandwich attack is relatively high, as low transaction fee leads to more potential profit.

The contract can set maximum wallet limit by updating mapping `walletLimit`. After `walletLimit` is set, every time the wallet receives a token, the received amount is added to `limitReached`, and if `limitReached` is larger than `walletLimit`, the transaction will revert. There are several potential issues in the current implementation: 1. If `walletLimit` is changed, the `limitReached` is set to 0. 2. Transfer token out of the address will not reduce `limitReached`. 3. After the limit is reached, the wallet cannot transfer tokens out of the wallet, but it can still receive tokens.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. ### External call(s) ```solidity= swapBack(amount); ``` * This function call executes the following external call(s). * In `FOMO.swapTokensForEth`, * `dexRouter.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` * In `FOMO.swapBack`, * `(success,None) = taxWallet.call{value: address(this).balance}("")` ### State variables written after the call(s) ```solidity=229 swapping = false; ``` ```solidity= super._update(from, to, amount); ``` * This function call executes the following assignment(s). * In `ERC20._update`, * `_balances[from] = fromBalance - value` * In `ERC20._update`, * `_balances[to] += value` ```solidity= super._update(from, to, amount); ``` * This function call executes the following assignment(s). * In `ERC20._update`, * `_totalSupply += value` * In `ERC20._update`, * `_totalSupply -= value`

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= IDexRouter public dexRouter; ``` - The contract `FOMO` interacts with third party contract with `IDexRouter` interface via `dexRouter`.

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.