Skip to content

Latest commit

 

History

History
57 lines (40 loc) · 2.17 KB

File metadata and controls

57 lines (40 loc) · 2.17 KB

Fast Khaki Raccoon

High

Handling tokens in the contract upon adding liquidity results in breaking the optimal one-sided supply amounts

Summary

Handling tokens in the contract upon adding liquidity results in breaking the optimal one-sided supply amounts

Root Cause

Upon processing rewards, part of the whole flow is the following:

  1. Convert a part of the paired LP token to a pod token
  2. 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.

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

  1. The optimal amounts are calculated
  2. Instead of swapping and using them, we get the tokens that are currently in the contract as well resulting in a non-optimal supply

Impact

Loss of funds due to a non-optimal liquidity supply

PoC

No response

Mitigation

Handle the tokens in the contract before the optimal supply calculation