HOPPY security record

**Transfer Tax Anomaly:** When the Hoppy contract sells tokens via the `swapTokensForEth()` function, a transfer tax is applied instead of a sell tax. Similarly, when the `_taxWallet` EOA buys tokens, a transfer tax is applied instead of a buy tax. **High Transfer Tax:** The transfer tax is significantly higher than both the buy and sell taxes until the `removeTransferTax()` function is executed. This discrepancy can lead to unexpectedly high fees during certain transactions, especially those involving the contract or tax wallet. **Detail Analysis:** 1. Initial Buy: Before the first buy transaction, the buy tax is applied. 2. Subsequent Buys: - Condition: If the recipient is not excluded from the fee (exclusions: owner, Hoppy contract, and `_taxWallet` EOA). - Action: Buy tax is applied. 3. Sell Transactions: - Condition: If the sender is not the Hoppy contract itself. - Action: Sell tax is applied. 4. Other cases: - Condition: For transfers not covered by the above conditions. - Action: A transfer tax of 75% is applied.

The transaction may be charged fees, so the max holding of the receiver should be the sum of the held tokens and the amount received from the transfer. The fees should not be included in the max holding. ```solidity=243 require(balanceOf(to) + amount <= _maxWalletSize, "Exceeds the maxWalletSize."); ```

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 back running (after the transaction being attacked) a transaction to sell the asset. The following function is called without setting restrictions on slippage or minimum output amount, so transactions triggering this function are vulnerable to sandwich attacks, especially when the input amount is large: - `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()` Additionally, the `_taxSwapThreshold` is set excessively high (1% of _tTotal), creating an arbitrage opportunity that can be monitored and exploited by MEV bots before the `swapTokensForEth()` function is executed.

State variables that are not updated following deployment should be declared constant to save gas.

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 IUniswapV2Router02 private uniswapV2Router; uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, path, address(this), block.timestamp ); ``` - The contract `Hoppy` interacts with third party contract with `IUniswapV2Router02` interface via `uniswapV2Router`. --- ```solidity uniswapV2Pair = IUniswapV2Factory(uniswapV2Router.factory()).createPair(address(this), uniswapV2Router.WETH()); IERC20(uniswapV2Pair).approve(address(uniswapV2Router), type(uint).max); ``` - The contract `Hoppy` interacts with third party contract with `IUniswapV2Factory` interface via `uniswapV2Router.factory()`. - The contract `Hoppy` interacts with third party contract with `IERC20` interface via `uniswapV2Pair`.

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.