GOUT security record

The `setAutoLPBurnSettings()` function is intended to configure the parameters for the automatic LP token burn process. According to the error message, the intended design is to ensure that the burn percentage does not exceed 5%. However, due to the way the percentage is calculated (`percentForLPBurn / percentDiv`), the current implementation allows the burn percentage to exceed 5% because `percentDiv` can be set arbitrarily high or low. ```soldiity=1375 function setAutoLPBurnSettings( uint256 _frequencyInSeconds, uint256 _percent, uint256 _div, bool _Enabled ) external onlyOwner { require(_percent <= 500, "percent too high"); require(_frequencyInSeconds >= 100, "frequency too shrot"); lpBurnFrequency = _frequencyInSeconds; percentForLPBurn = _percent; percentDiv = _div; lpBurnEnabled = _Enabled; } ```

The `_transfer` function enforces a restriction where users must retain a minimum balance of `_minWallet` (set to 8 * 10^18, equivalent to 8 tokens) in their accounts. The relevant logic: ```solidity function _transfer( address from, address to, uint256 amount ) internal virtual override { if(from != address(this) && balanceOf(from).sub(amount) < _minWallet) { amount = balanceOf(from).sub(_minWallet); } ``` effectively limits the transfer amount if the transaction would cause the sender's balance to fall below `_minWallet`. As a result, users are unable to fully utilize their token balance, leaving 8 tokens "locked" in every account. This design can cause confusion and frustration among users, as they might expect to withdraw or transfer their entire balance but are prevented from doing so without a clear explanation or documentation of this restriction.

An SPDX (Software Package Data Exchange) license identifier is a standardized short-form identifier for software licenses. These identifiers are used to communicate the licensing components of software packages in a concise, consistent, and machine-readable manner. Placing the SPDX license identifier on the first line of a file is a best practice because it enhances visibility, ensures consistency, supports tool compatibility, and aids in standardizing license documentation across codebases. However, in the file, the SPDX license identifier is misplaced, thus the best practice is not followed. For more references: 1. [SPDX Official Website](https://spdx.org) 2. [GitHub Licensing a Repository Help Page**](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/licensing-a-repository) 3. [Open Source Initiative (OSI)](https://opensource.org/licenses/MIT) 4. [SPDX License List](https://spdx.org/licenses/)

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The `multiTransfer()` function uses `addrs` and `amounts` arrays in a single `transfer()` function call. Therefore, the elements of arrays must correspond one-to-one, and their lengths must match. However, the function does not perform this check.

A sandwich attack can occur when an attacker notices a transaction involving token swaps or liquidity additions that lacks slippage restrictions or minimum output amount settings. The attacker can exploit this by frontrunning the transaction to purchase one of the assets, thereby manipulating the exchange rate, and then backrunning the transaction to sell the asset for a profit. The referenced functions are invoked without setting slippage restrictions or minimum output amounts, making transactions that trigger these functions particularly vulnerable to sandwich attacks, especially when large input amounts are involved.

The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

Solidity version >=0.8.0 includes checked arithmetic operations and underflow/overflow by default, making SafeMath redundant.