Basenji security record

In the contract `Basenji` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - enable trading - remove limits after the token is stable - disable transfer delay - set early sell tax - change the minimum amount of tokens to sell from fees - add to launch - update the maximum transaction amount - update the maximum wallet amount - exclude from the maximum transaction or include in the maximum transaction - update the swap switch - update buy/sell fees - set blacklist account - set check blacklist switch - update `devWallet` and `marketingWallet` address - set auto-mated market maker pair  In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and renounce the ownership of the contract and transfer the ownership of the contract to any address. 

The contract `Basenji` 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. ```solidity if (!tradingActive) { require( _isExcludedFromFees[from] || _isExcludedFromFees[to], "Trading is not active." ); ```

Liquidity swapped in function `swapBack` was not added to the dex pair but was instead sent to the marketing wallet, which conflicts with the code comment and variable naming. ```solidity=1609 uint256 liquidityTokens = (contractBalance * tokensForLiquidity) / totalTokensToSwap / 2; uint256 amountToSwapForETH = contractBalance.sub(liquidityTokens); ``` ```solidity=1626 (success, ) = address(marketingWallet).call{ value: address(this).balance }(""); ```

The `setAutomatedMarketMakerPair` function in the Basenji token contract allows the contract owner to designate pairs as automated market maker (AMM) pairs without any restrictions. This function lacks validation checks to prevent the removal or alteration of the primary liquidity pair. Malicious actors with control over the contract can exploit this functionality to redirect trades to a different pair, potentially draining liquidity or manipulating the market. Additionally, the new pair is not excluded from the maximum transaction limit.

According to the code's comments, this function should only be called once. But now there is no limit to calling once. If multiple calls are made, the variable `launchedAt` will be updated to the `block.number`. This will result in some users being added to the `_blacklist` mapping by mistake.

If a reentrancy attack happened during the swapping process in the function `_transfer`, the `swapping` could be `true` in L1532, then the `takeFee` would always be `false`. Therefore, any transfer performed in a reentrancy attack would avoid fees for the attacker even if the attacker address is not excluded from fees.

The `_owner` can set the `sellFees` to high values, up to 99%, through the `updateSellFees` function. These fees represent the percentage taken as fees for selling basenji tokens through a trading pair. Setting such disproportionately high fees can severely impact the token's marketability and user trust, as it implies that nearly all of the transaction value could be deducted as fees, leaving minimal actual value for the traders.