Liquid Protocol security record

All of the `1e6 * 10**9` tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can 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.

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

In the function `_tokenTransfer()`, when the `rLiquidity` or `tLiquidity` is greater than 0, the event `Transfer` is emitted with a value equal to the sum of `tLiquidity`, `tMarketing` and `tDonation`. Consequently, if the `rLiquidity` and `tLiquidity` both equal 0, the event cannot be emitted, even if `rMarketing`, `tMarketing`, `rDonation`, and `tDonation` are greater than 0.

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 backrunning (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 - router.addLiquidityETH

State variables that never change should be declared as `constant` to save gas. ```solidity=153 uint256 private _tTotal = 1e6 * 10**_decimals; ``` - `_tTotal` should be declared `constant`.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=147 IRouter public router; ``` - The contract `liquidprotocol` interacts with third party contract with `IRouter` interface via `router`.

The linked `transfer()`/`transferFrom()` invocations do not check the return value of the function call which should yield a `true` result in case of proper ERC-20 implementation.

The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. ```solidity=586 router.addLiquidityETH{value: bnbAmount}( address(this), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable owner(), block.timestamp ); ```

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