Peezy - Audit

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 `_transfer()` function in the contract is vulnerable to a denial-of-service (DoS) attack. The vulnerability arises from the `sellCount` mechanism, which limits the number of sell transactions to 3 per block. The `swapTokensForEth()` function swaps the minimum amount among `amount`, `contractTokenBalance`, and `_maxTaxSwap`, allowing an attacker to exploit the system by repeatedly initiating small token transfer amounts (e.g., 1 token) under certain situations. This attack can effectively block all other sell transactions within the same block. ```solidity=252 if (!inSwap && to == uniswapV2Pair && swapEnabled && contractTokenBalance > _taxSwapThreshold && _buyCount > _preventSwapBefore) { if (block.number > lastSellBlock) { sellCount = 0; } require(sellCount < 3, "Only 3 sells per block!"); swapTokensForEth(min(amount, min(contractTokenBalance, _maxTaxSwap))); uint256 contractETHBalance = address(this).balance; if (contractETHBalance > 0) { sendETHToFee(address(this).balance); } sellCount++; lastSellBlock = block.number; } ```

The maximum wallet limit `_maxWalletSize` could be bypassed through the `owner` address because of excluding the address from the check. The address `owner` can be used as the transit address to break the maximum wallet limit.

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=238 require(balanceOf(to) + amount <= _maxWalletSize, "Exceeds the maxWalletSize."); ``` - Max holding is checked. ```solidity=268 _balances[to]=_balances[to].add(amount.sub(taxAmount)); ``` - Receiving amount is adjusted. ```solidity=268 _balances[to]=_balances[to].add(amount.sub(taxAmount)); ``` - Balance is increased by the adjusted amount.

The `PEEZY` contract is serving as the underlying entity to interact with third-party `uniswapV2Router`. 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.

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=303 _taxWallet.transfer(amount); ``` - `PEEZY.sendETHToFee` uses `transfer()`.