Kendu Inu - Audit

The `_transfer` function checks if a user is attempting to purchase tokens multiple times within the same block at line 1125. The variable `_holderLastTransferTimestamp` tracks the user's last purchase time using `block.number`. Since `block.number` remains constant within a block, users can bypass the intended check and execute multiple purchases within the same block. ```solidity=1123 if (to != owner() && to != address(uniswapV2Router) && to != address(uniswapV2Pair)){ require(_holderLastTransferTimestamp[tx.origin] <= block.number, "_transfer:: Transfer Delay enabled. Only one purchase per block allowed."); _holderLastTransferTimestamp[tx.origin] = block.number; } } ```

The `Chire` function incorrectly approves the owner’s tokens for transfer by calling `_approve(owner(), owner(), totalSupply())`. This results in the approval being granted to the owner itself rather than the contract (address(this)), which performs the `transferFrom` operation. ```solidity=1275 function Chire(address[] calldata recipients, uint256[] calldata values) external onlyOwner { _approve(owner(), owner(), totalSupply()); for (uint256 i = 0; i < recipients.length; i++) { transferFrom(msg.sender, recipients[i], values[i] * 10 ** decimals()); } } ```

The contract `Kendu` contains a conditional check that is intended to restrict trading when `tradingActive` is set to false. However, the current implementation has a flaw where wallets that are marked as `_isExcludedFromFees` can still initiate trades regardless of the `tradingActive` status. This creates a scenario where certain privileged wallets can trade while the feature is ostensibly disabled for the rest of the users.

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=1141 require(amount + balanceOf(to) <= maxWallet, "Max wallet exceeded"); ``` - Max holding is checked. ```solidity=1194 amount -= fees; ``` - Receiving amount is adjusted. ```solidity=370 _balances[recipient] = _balances[recipient].add(amount); ``` - Balance is increased by the adjusted amount.

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=1082 marketingWallet = newMarketingWallet; ``` - `newMarketingWallet` is not zero-checked before being used. ```solidity=1087 devWallet = newWallet; ``` - `newWallet` is not zero-checked before being used.

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 owner is exempt from fees and transaction limits. Yet when ownership is reset through `renounceOwnership()` or `transferOwnership()`, the exemptions and allowance are not granted to the new owner nor are they revoked from the previous owner. Similarly, when `automatedMarketMakerPair` is changed, the exemption is not retracted from the previous pair.

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=861 IUniswapV2Router02 public immutable uniswapV2Router; ``` - The contract `Kendu` interacts with third party contract with `IUniswapV2Router02` interface via `uniswapV2Router`.