AIDOGE security record

### Original #### Owner In the contract `AIERC20` the role `_owner` has authority over the functions listed below. - `doSwapBack()`: trigger the swap manually. - `setFees()`: set the fee. - `setFeeReceivers()`: set the fee receivers. - `setIsFeeExempt()`: set the `isFeeExempt`. - `setSwapBackSettings()`: enable/disable swap. - `addPair()`: add pair address into `_pairs`. - `delPair()`: remove pair address from `_pairs`. - `renounceOwnership()`: renounce the ownership. - `transferOwnership()`: transfer the ownership to a specified address. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the configuration of the contract. #### Team wallet In the contract `AIERC20` the role `teamWallet` has authority over the functions listed below. - `setTeamWallet()`: change the team wallet. Any compromise to the `teamWallet` account may allow the hacker to take advantage of this authority and change the `teamWallet`. --- ### Update The following content is based on the version (07/12/2023). In the contract `AIERC20`, the role `_owner` has authority over the functions listed below. - `renounceOwnership()`: renounce the ownership. - `transferOwnership()`: transfer the ownership to a specified address. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the ownership of the contract. The role `teamWallet` and its privileged functions have been removed in this version. --- ### Update #### Owner The following content is based on the version (07/28/2023). In the contract `AIERC20` the role `_owner` has authority over the functions listed below. - `doSwapBack()`: trigger the swap manually. - `initializePair()`: initialize trade pair. - `setFees()`: set the fee. - `setFeeReceivers()`: set the fee receivers. - `setIsFeeExempt()`: set the `FeeExempt` related info. - `setIsFromFeeExempt()`: set the `isFromFeeExempt`. - `setIsToFeeExempt()`: set the `isToFeeExempt`. - `setIsSenderFeeExempt()`: set the `isSenderFeeExempt`. - `setSwapBackSettings()`: enable/disable swap. - `addPair()`: add pair address into `_pairs`. - `delPair()`: remove pair address from `_pairs`. - `renounceOwnership()`: renounce the ownership. - `transferOwnership()`: transfer the ownership to a specified address. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the configuration of the contract. #### Team wallet In the contract `AIERC20` the role `teamWallet` has authority over the functions listed below. - `setTeamWallet()`: change the team wallet. - `setIsFeeExempt()`: set the `isFeeExempt`. - `setIsFromFeeExempt()`: set the `isFromFeeExempt`. - `setIsToFeeExempt()`: set the `isToFeeExempt`. - `setIsSenderFeeExempt()`: set the `isSenderFeeExempt`. Any compromise to the `teamWallet` account may allow the hacker to take advantage of this authority to set fee exemptions. --- ### Update #### Owner The following content is based on the version (08/07/2023). In the contract `AIERC20` the privileged functions of the role `_owner` changed as below: #### Added - `setSysFeeExempt()`: set the `FeeExempt` related info. - `clearStuckEthBalance()`: clear stuck native tokens. #### Changed - `doSwapBack()`: removed the `onlyOwner` modifier. - `initializePair()`: removed the `onlyOwner` modifier.

All of the `AIERC20` tokens are sent to the specified address `_mintTo`. This is a centralization risk because the the owner(s) of the EOA can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

After adding liquidity to the pair, the contract emits an event `AddLiquidity` with a pre-calculated value. However, it should be noted that due to price changes caused by previous swaps, the pre-calculated amount of assets may not be added to the pair exactly as expected. Therefore, using these values to emit the `AddLiquidity` event will be inaccurate since they are not the actual values that are added to the pair. ```solidity=227 try swapRouter.addLiquidityETH{value: ethAmount}(address(this), half, 0, 0, address(0), block.timestamp) { emit AddLiquidity(half, ethAmount, block.timestamp); } catch {} ```

The new `teamWallet` is intended to be updated with original `teamWallet`: ```solidity=276 function setTeamWallet(address _teamWallet) external { require(msg.sender == teamWallet, "Only team wallet can change team wallet"); teamWallet = _teamWallet; emit SetTeamWallet(msg.sender, _teamWallet); } ``` However, in the current logic, it can be updated by the owner via `setFeeReceivers`.

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=268 bounsWallet = _bounsWallet; ``` - `_bounsWallet` is not zero-checked before being used. --- ```solidity=270 teamWallet = _teamWallet; ``` - `_teamWallet` is not zero-checked before being used. --- ```solidity=275 teamWallet = _teamWallet; ``` - `_teamWallet` is not zero-checked before being used.

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. 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: - `_doAddLp()` ```solidity=200 ISwapRouter.ExactInputSingleParams memory params = ISwapRouter.ExactInputSingleParams({ tokenIn: address(this), tokenOut: address(WETH), fee: StandardPoolFee, recipient: address(this), deadline: block.timestamp, amountIn: half, amountOutMinimum: 0, // @audit sandwich sqrtPriceLimitX96: 0 }); uint256 outAmount = swapRouter.exactInputSingle(params); ``` --- ### Updates The following content is based on the version (07/28/2023). The contract used `UniswapV2` relevant contracts instead of `UniswapV3` to implement the business logic. This issue still exists in the below code: ```solidity=214 try swapRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens(half, 0, pathEth,address(this),block.timestamp){ uint256 ethAmount = WETH.balanceOf(address(this)) - ethAmountBefore; try swapRouter.addLiquidity(address(this), address(WETH), half, ethAmount, 0, 0, address(0), block.timestamp) { emit AddLiquidity(tokenAmount, ethAmount, block.timestamp); } catch {} } catch {} ```

The `_fullFeeExempt` is used to store the holders who are marked as `true` in the `isFromFeeExempt`, `isToFeeExempt` and `isSenderFeeExempt` mappings. However, the contract only sets `_fullFeeExempt` in the `setIsFeeExempt()` function. If the owner sets this information using other functions such as `setSysFeeExempt()`, `setIsFromFeeExempt()`, etc... the `_fullFeeExempt` variable will not be updated accordingly. As a result, a inconsistency issue will arise.

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=62 address public bounsWallet; ``` - The contract `AIERC20` interacts with third party contract with `IAIERC20BounsPool` interface via `bounsWallet`. --- ```solidity=63 IAIERC20TradingPool public tradingPool; ``` - The contract `AIERC20` interacts with third party contract with `IAIERC20TradingPool` interface via `tradingPool`. --- ```solidity=68 ISwapRouter public immutable swapRouter; ``` - The contract `AIERC20` interacts with third party contract with `ISwapRouter` interface via `swapRouter`. --- ```solidity=69 INonfungiblePositionManager public immutable nonfungiblePositionManager; ``` - The contract `AIERC20` interacts with third party contract with `INonfungiblePositionManager` interface via `nonfungiblePositionManager`. --- ```solidity=70 IWETH public immutable WETH; ``` - The contract `AIERC20` interacts with third party contract with `IWETH` interface via `WETH`. --- ### Updates The following content is based on the version (07/28/2023). New third party dependencies are as listed below. ```solidity=63 IUniswapV2Router02 public immutable swapRouter; ``` - The contract `AIERC20` interacts with third party contract with `IUniswapV2Router02` interface via `swapRouter`. --- ```solidity=64 IUniswapV2Factory public immutable swapFactory; ``` - The contract `AIERC20` interacts with third party contract with `IUniswapV2Factory` interface via `swapFactory`. Note: The `ISwapRouter` and `INonfungiblePositionManager` are removed in current version.