Alphabet security record

The role `owner` in **Alphabet** contract has authority over the following functions: - **`rescueBNB()`**: Rescue the native tokens stuck in the contract to the owner; - **`rescueAnyBEP20Tokens()`**: Rescue **any** ERC-20-compatible tokens(including lp token) stuck in the contract to the owner; - `renounceOwnership()`: Set the owner address to zero address; - `transferOwnership()`: Transfer the owner address to an arbitrary non-zero address; - `setTradingStatus()`: Enable/Disable the token transferring and `swapAndLiquify` during token transfers; - `excludeFromFee()`: Exempt an arbitrary EOA from paying transaction fees; - `includeInFee()`: Include an arbitrary EOA to pay transaction fees; - `excludeFromReward()`: Restrict an arbitrary EOA from receiving rewards as a holder; - `includeFromReward()`: Allow an arbitrary EOA to receive rewards as a holder; - `setTaxes()`: Set the transfer fee amount; - `setSellTaxes()`: Set the sell taxes; - `airdropTokens()`: Transfer the tokens from the caller to a set of addresses; - `bulkExcludeFee()`: Exempt a list of addresses from paying transaction fees; - `__Update_MarketingWallet()`: Update the marketing wallet address; - `__Update_TeamWallet()`: Update the team wallet address; - `updateCooldown()`: Update the cooldown time and enable/disable the trading cooldown; - `updateSwapTokensAtAmount()`: Update the token swap amount; - `updateSwapEnabled()`: Enable/Disable the `swapAndLiquify` mechanism; - `updateIsBlacklisted()`: Put/remove an arbitrary EOA on/from the blacklist; - `bulkIsBlacklisted()`: Update the blacklist status for a list of addresses; - `updateAllowedTransfer()`: Allow/Restrict an address to/from transferring tokens; - `Update_Max_Tx_Limit()`: Update the max amount of tokens transferred in one transaction; - `Update_Max_Wallet_Holding()`: Update the max amount of tokens an address can hold; - `updateRouterAndPair()`: Update the router and pair addresses. Any compromise to the `owner` account may allow a hacker to take advantage of this authority and manipulate the program settings, even withdraw ERC20 tokens and BNB from the contract.

All **Alphabet** tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute **Alphabet** tokens without the consensus of the community.

The `addLiquidity` function calls the `router.addLiquidityETH` function with the `to` address specified as `owner()` for acquiring the generated LP tokens from the pool. As a result, over time, the owner address will accumulate a significant portion of LP tokens. If the owner is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole. ```solidity=578 router.addLiquidityETH{value: bnbAmount}( address(this), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable owner(), block.timestamp ); ```

The `rescueAnyBEP20Tokens` function allows the contract owner to withdraw a specific type of BEP20/ERC20 compatible token from the contract. ```solidity=677 function rescueAnyBEP20Tokens(address _tokenAddr, address _to, uint _amount) public onlyOwner { IERC20(_tokenAddr).transfer(_to, _amount); } ``` However, there is no restriction on the token type parameter (`_tokenAddr`). This could potentially allow the owner to withdraw Alphabet tokens as well as the LP token(if any) inside the contract, which might result in insufficient funds for the `swapAndLiquify` process, etc.

In function `_transfer` there is a limitation on the left token in user(sender) account: ```solidity=502 if(balanceOf(from) - amount <= 10 * 10**decimals()) amount -= (10 * 10**decimals() + amount - balanceOf(from)); ``` This means user should keep at least `10 * 10** decimals()` in the account and these token cannot be trade.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=555 uint256 unitBalance= deltaBalance / (denominator - temp.liquidity); ``` ```solidity=556 uint256 bnbToAddLiquidityWith = unitBalance * temp.liquidity; ```

When adding liquidity, the amount of ALT token being added for liquidity is `(contractBalance * temp.liquidity) / denominator`. Theoretically, it should swap the same amount of tokens to BNB for adding liquidity. However, the amount of BNB used for adding liquidity is `deltaBalance * temp.liquidity / (denominator - temp.liquidity)`, which is more than the ALT token used.

The `updateSwapTokensAtAmount` function is used to update the threshold value `swapTokensAtAmount` for the `swapAndLiquify` process. However, there are no constraints on the new value for `swapTokensAtAmount`. Consequently, if the updated `swapTokensAtAmount` is set too high, it could prevent the contract from ever executing the `swapAndLiquify` function.

The `setTaxes` and `setSellTaxes` functions in the given contract are designed to update the fee settings for the token. However, there are no restrictions in place to limit the fee updates, which can potentially result in arbitrary fee values being set. For instance, an individual fee might be set to exceed 100, or the total sum of fees might exceed 100, both of which could lead to issues with token transfers.

When updating `_owner`, `Marketing_Wallet` and `Team_Wallet` to new addresses in the following methods: - `renounceOwnership()` - `transferOwnership(address newOwner)` - `__Update_MarketingWallet(address newWallet)` - `__Update_TeamWallet(address newWallet)` The `_isExcludedFromFee` and `allowedTransfer` identifiers are not removed from the original addresses. Meanwhile, new addresses are not granted with the aforementioned identifiers.