QMGF-Audit

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=853 _marketAddr = value; ``` - `value` is not zero-checked before being used. --- ```solidity=976 _nft = value; ``` - `value` is not zero-checked before being used. --- ```solidity=983 token.call(abi.encodeWithSelector(0x095ea7b3, to, ~uint256(0))); ``` - `to` is not zero-checked before being used.

Performing division by zero would raise an error and revert the transaction. ```solidity=655 uint256 everyNftDivi = _nftAllDivi / NFT(_nft).totalSupply(); ``` The expression `_nftAllDivi / NFT(_nft).totalSupply()` may divide by zero. Its divisor has an estimated interval [0, 115792089237316195423570985008687907853269984665640564039457584007913129639935]. --- ```solidity=703 uint256 amount = tokenBal .mul( IERC20(_uniswapV2Pair).balanceOf( _shareholders[_currentIndex] ) ) .div(getLpTotal()); ``` The expression `tokenBal.mul(IERC20(_uniswapV2Pair).balanceOf(_shareholders[_currentIndex])).div(getLpTotal())` may divide by zero. Its divisor has an estimated interval [0, 115792089237316195423570985008687907853269984665640564039457584007913129639935].

A sandwich attack might 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 (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: ```solidity=966 _uniswapV2Router.swapExactTokensForTokensSupportingFeeOnTransferTokens( tokenAmount, 0, path, address(0xdead), block.timestamp ); ``` ```solidity=884 _uniswapV2Router.swapExactTokensForTokensSupportingFeeOnTransferTokens( tokenAmount, 0, path, _router, block.timestamp ); ```

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

State variables that never change should be declared as `constant` to save gas. ```solidity=339 uint256 _distributorGas = 500000; ``` - `_distributorGas` should be declared `constant`.

In the `_transfer()` function, if either `_fromAddress` or `_toAddress` is not listed in `_isDividendExempt` and is not identical to `_uniswapV2Pair`, these addresses will be incorporated into `_shareholders`. Nevertheless, as depicted in lines 617 and 618, when `_fromAddress` or `_toAddress` doesn't equate to `address(0)`, these addresses maintain the from and to values from the previous `_transfer()` invocation, as opposed to those from the current operation. As a consequence, the `from` and `to` addresses from the last transaction does not become shareholders.

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=666 IERC20(_token).transferFrom(_nftRouter, NFT(_nft).ownerOf(_nftIndex),tokenIdDivi); ``` --- ```solidity=797 IERC20(_rewardToken).transfer(_nftRouter, nftD); ``` --- ```solidity=798 IERC20(_rewardToken).transfer( _marketAddr, tokenBal.mul(_buyMarketingFee.add(_sellMarketingFee)).div( _denominator ) ); ``` --- ```solidity=804 IERC20(_rewardToken).transfer( _lpRouter, tokenBal.mul(_buyLpFee.add(_sellLpFee)).div(_denominator) ); ``` --- ```solidity=808 IERC20(_rewardToken).transfer( _marketRouter, IERC20(_rewardToken).balanceOf(address(this)) ); ``` --- ```solidity=891 IERC20(_token).transferFrom( _router, address(this), IERC20(_token).balanceOf(address(_router)) ); ``` --- ```solidity=954 IERC20(_token).transferFrom(_marketRouter, address(this), 500e18); ```

The low-level `call` function returns the status of the call as first variable in the returned tuple. The status of the `call` is not asserted to be `true`, which would treat the low-level call as a success even when it reverted. ```solidity=393 _token.call( abi.encodeWithSelector(0x095ea7b3, _uniswapV2Router, ~uint256(0)) ); ``` --- ```solidity=983 token.call(abi.encodeWithSelector(0x095ea7b3, to, ~uint256(0))); ```

The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=126 library SafeMath { ``` - An implementation of `SafeMath` library is found. --- ```solidity=304 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `GGGTOKEN` contract. ```solidity=354 _swapTokensAtAmount = _tTotal.mul(1).div(10**4); ``` - `SafeMath.mul` is called in `constructor` function of `GGGTOKEN` contract. *Note: Only a sample of 2 `SafeMath` library usage in this contract (out of 36) are shown above.*

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.