Alphabet Audit

CertiK4 May 20231 address on BNB Chain

Audit

CertiK reviewed Alphabet (Alphabet Audit) on 4 May 2023: 15 findings, 0 critical; all acknowledged, none fixed.

No open critical findings

Open the report Open Alphabet’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings15

Statuses are the security firm’s own, from its report.

Severity	Open	Acknowledged	Fixed
Critical	0	0	0
High	0	2	0
Medium	0	2	0
Low	0	11	0

HighCentralization Related RisksAcknowledged

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.

HighInitial Token DistributionAcknowledged

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.

MediumLiquidity Generated from transferring are sent toAcknowledged

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 ); ```

MediumMissing Input Validation on `_tokenAddr`Acknowledged

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.

LowDiscussion on Untradable amountAcknowledged

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.

LowDivide Before MultiplyAcknowledged

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; ```

LowImbalance token amount between ALT and BNB when aAcknowledged

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.

LowMissing Input Validation on `updateSwapTokensAtAmAcknowledged

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.

LowMissing Input Validation on TaxesAcknowledged

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.

LowMissing Update `_isExcludedFromFee` and `allowedTAcknowledged

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.

Show 5 more

LowMissing Zero Address ValidationAcknowledged

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=209 pair = _pair; ``` - `_pair` is not zero-checked before being used. --- ```solidity=620 Marketing_Wallet = newWallet; ``` - `newWallet` is not zero-checked before being used. --- ```solidity=624 Team_Wallet = newWallet; ``` - `newWallet` is not zero-checked before being used. --- ```solidity=667 pair = newPair; ``` - `newPair` is not zero-checked before being used.

LowPotential Inconsistency on Sell Operation DetermiAcknowledged

In the `_transfer` function, the sell operation is identified at line 485 with the following code: ```solidity=489 if(from != pair && !_isExcludedFromFee[to] && !_isExcludedFromFee[from] && !swapping){ require(amount <= Max_Sell_Limit, "You are exceeding Max_Sell_Limit"); ``` This implies that if the `from` address is not the `pair`, the transaction will be treated as a sell, regardless of the `to` address. However, the transaction is reevaluated at line 513: ```solidity=513 if(to == pair) isSell = true; ``` Here, `isSell` is determined based on the `to` address, which creates inconsistency when the `to` address is another user and not the pair. This inconsistency can impact the taxes and fees applied during the transaction.

LowPotential Sandwich AttacksAcknowledged

A sandwich attack might 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 (before the transaction being attacked) a transaction to purchase one of the assets and make profits by back running (after the transaction being attacked) a transaction to sell the asset. The following 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: - `router.swapExactTokensForETHSupportingFeeOnTransferTokens`

LowUsage of `transfer`/`send` for sending EtherAcknowledged

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring Ether, 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=673 payable(msg.sender).transfer(weiAmount); ``` - `ALPHABET.rescueBNB` uses `transfer()`.

LowVariable `_rOwned[account]` Not Updated in FunctiAcknowledged

Variable `_rOwned[account]` is not updated in the function `includeInReward()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The Rate was higher at the moment of the `excludeFromReward(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward.