LedgerAI - Audit

In the contract `Ledger` the role `_owner` has authority over the functions listed below. - transferOwnership() - renounceOwnership() - updateTaxStructure() - excludeFromMaxTransaction() - setAutomatedMarketMakerPair() - excludeFromFees() - transferForeignToken() - setOperationsAddress() - setMarketingAddress() - removeLimits() - restoreLimits() - flagSniper() - massFlagSnipers() - unflagSniper() - massUnflagSnipers() - recoverETH() - prepareLaunch() - enableTrading() - prepareForMigration() - disableV3LPProtection() - setSwapRestrictions() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority, update the configuration of the contract, and transfer assets.

All of the `LEDGER` tokens are sent to the current token contract during the deployment. However, it is noted that when the trade is not enabled, the owner can withdraw all the tokens to the `_to` address by calling `transferForeignToken` function. This is a centralization risk because the `_to` accounts may 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.

The `prepareLaunch` function is designed to set up liquidity pools for this address and WETH on both Uniswap V2 and V3. However, the function only configures the exclusion of fees and maximum transaction settings for the Uniswap V2 pair and router. Additionally, liquidity is only added to the Uniswap V2 pool, not the Uniswap V3 pool. ```solidity // Relevant code snippet _excludeFromMaxTransaction(address(uniswapV2Pair), true); _setAutomatedMarketMakerPair(address(uniswapV2Pair), true); _excludeFromMaxTransaction(address(uniswapV2Router), true); excludeFromFees(address(uniswapV2Router), true); // Uniswap V3 Pair is created but not configured similarly uniswapV3Pair = IUniswapV3Factory(uniswapV3Router.factory()).createPool( address(this), uniswapV2Router.WETH(), 10000 ); // Liquidity is added only to Uniswap V2 pool uniswapV2Router.addLiquidityETH{value: address(this).balance}( address(this), balanceOf(address(this)), 0, // slippage is unavoidable 0, // slippage is unavoidable msg.sender, block.timestamp ); ```

The `_update` function within the ERC20 token contract is intended to handle token transfers while enforcing various restrictions, including max wallet size. The function contains a logic flaw in the check that ensures a recipient's balance does not exceed `maxWallet` after a transfer. The check incorrectly includes the transaction fee in the `amount` being added to the recipient's balance, which could lead to a situation where the actual token balance received by the `to` address is less than `maxWallet`, but the transaction is still rejected. ```solidity // Incorrect check that does not account for fee deduction require( amount + balanceOf(to) <= maxWallet, "Max Wallet Exceeded" ); ``` This issue arises because the fee is deducted after this check, potentially leading to a scenario where legitimate transactions that should not exceed the `maxWallet` limit are being prevented.

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 cited 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.