$SHARBI

All **SHARBI** tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute **SHARBI** tokens without the consensus of the community. The detailed holder list can be found at Etherscan: https://etherscan.io/token/0xf3a3023e6dede84ad88a656a3269f2a36e83c9a9#balances

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

When a transfer happens and the conditions in `shouldSwapBack()` are met, the function `swapBack()` is invoked. However, `swapBack()` uses `_liquidityFeeCount` and `_reflectionFeeCount`. Their initial value is zero by default and is set to zero again after `swapBack()` completes its execution. Their value is changed only in `setBuyAccFee()` and `setSellAccFee()` after transfers to/from the pair. ```solidity=791 uint256 amountToLiquify = swapThreshold .mul(_liquidityFeeCount) .div(totalFee) .div(2); ``` In a certain scenario, this logic will cause `swapBack()` to revert: 1. Suppose that `swapBack()` is invoked before any transfer occurs to/from the pair or that two `swapBack()` executions occur after some time, but in the meanwhile no transfer is happened to/from the pair 2. In both the scenarios described in the previous point, `_liquidityFeeCount` and `_reflectionFeeCount` are zero 3. The current execution of `swapBack()` will calculate a value for `totalFee` equal to zero at line 789 4. At line 793 when calculating `amountToLiquify` a division by zero occurs, and function revert Another situation that could occur would be small amounts being transferred and used in the `setBuyAccFee()` and `setSellAccFee()` functions. The amounts that might be truncated by division by the `feeDenominator` and would not update the `_liquidityFeeCount` and `_reflectionFeeCount` values. ```solidity=764 function setBuyAccFee(uint256 _amount) internal { _liquidityFeeCount += _amount.mul(_liquidityBuyFee).div(feeDenominator); _reflectionFeeCount += _amount.mul(_reflectionBuyFee).div( feeDenominator ); } function setSellAccFee(uint256 _amount) internal { _liquidityFeeCount += _amount.mul(_liquiditySellFee).div( feeDenominator ); _reflectionFeeCount += _amount.mul(_reflectionSellFee).div( feeDenominator ); } ```