Fast Khaki Raccoon
High
Handling tokens in the contract upon adding liquidity results in breaking the optimal one-sided supply amounts
Handling tokens in the contract upon adding liquidity results in breaking the optimal one-sided supply amounts
Upon processing rewards, part of the whole flow is the following:
- Convert a part of the paired LP token to a pod token
- Supply them as liquidity
In order to convert an amount of paired LP tokens such that it is optimal (we can not simply convert half as this is not optimal at all), the following function is used based on this article:
function _getSwapAmt(address _t0, address _t1, address _swapT, uint256 _fullAmt) internal view returns (uint256) {
(uint112 _r0, uint112 _r1) = DEX_ADAPTER.getReserves(DEX_ADAPTER.getV2Pool(_t0, _t1));
uint112 _r = _swapT == _t0 ? _r0 : _r1;
return (_sqrt(_r * (_fullAmt * 3988000 + _r * 3988009)) - (_r * 1997)) / 1994;
}
The issue is that after the swap, we have the following code:
_podAmountOut = pod.balanceOf(address(this));
_pairedRemaining = IERC20(_pairedLpToken).balanceOf(address(this)) - _protocolFees;
...
try indexUtils.addLPAndStake(pod, _podAmountOut, _pairedLpToken, _pairedRemaining, _pairedRemaining, lpSlippage, _deadline) returns (uint256 _lpTknOut) {
...
}
We get the whole balance to handle any tokens that are left in the contract from previous runs (this is expected and extremely likely, the code handles it for a reason, we are working with AMMs after all). The issue is that this clearly breaks the previously calculated optimal supply, causing a non-optimal LP and thus, a loss of funds.
No response
No response
- The optimal amounts are calculated
- Instead of swapping and using them, we get the tokens that are currently in the contract as well resulting in a non-optimal supply
Loss of funds due to a non-optimal liquidity supply
No response
Handle the tokens in the contract before the optimal supply calculation