Hedging against impermanent loss when staking your LP for $TEAK

Hey Kangalians,

We have been thinking about how to incentivize LP staking properly, with impermanent loss in mind, and we came up with a solution that we want to share with you all.

(Before diving into the solution, please see this article in case you do not know much about what is impermanent loss.)

As you know, the market cap of KANGAL is around 3M right now, and if you look at our price chart you can see we are pretty far away from our ATH. This means we have a lot of upward potential and at a place where the potential impermanent loss might be stopping people from becoming a liquidity provider and staking LP for $TEAK rewards.

In order to solve this and incentivize staking KANGAL/BNB LP tokens, we are proposing to persist the information of KANGAL/BNB amount staked when user stakes LP tokens, and calculate the rewards from this saved amount if the price went up since the user staked their LP tokens. To give an example, let’s think that you deposited 10M KANGAL and the corresponding BNB today, the staking contract will save this amount (10M x 2, actually, to account for the corresponding BNB amount) at the time of staking, and when the rewards are calculated it will be using this saved amount (20M KANGAL) the current amount calculated for LP is not higher than the saved amount. If the current amount corresponding to LP tokens is higher than the saved amount, than the current amount will be used. Let’s go over the examples of the two cases possible, first being the scenario where the price goes up and the other is where the price goes down.

Scenario where the KANGAL price goes up after staking your LP tokens:

  1. You stake LP tokens that correspond to 10M KANGAL / 1 BNB
  2. Staking contract saves your staking amount as 20M (10M * 2, because it includes the BNB added)
  3. KANGAL price goes up, the KANGAL/BNB amount corresponding to your LP is now different (less KANGAL, more BNB), but because your initial amount was saved as 20M KANGAL, you are protected against impermanent loss for the reward calculation.

Scenario where the KANGAL price goes down after staking your LP tokens:

  1. You stake LP tokens that correspond to 10M KANGAL / 1 BNB
  2. Staking contract saves your staking amount as 20M (10M * 2, because it includes the BNB added)
  3. KANGAL price goes down, the KANGAL/BNB amount corresponding to your LP is now different (more KANGAL, less BNB), since the corresponding amount to your LP tokens are now different (more KANGAL because price went down), the saved info about 20M KANGALs is ignored and your rewards are calculated with the current ratio.

As you can see this will protect the LP token stakers even if the price goes up as long as they do not withdraw and exit their positions, while also taking into account the case where the price goes down.

Would love to hear your thoughts or explain any points that were not clear enough, so feel free to shoot your questions! :slight_smile:

3 Likes

This sounds just about great. Thanks for the detailed explanation and examples, very useful. I’m a beginner and it all made sense. :slight_smile:

1 Like

This is a good idea. This will make providing liquidity more attractive than just staking Kangals.

Also, let’s say that the market is going down and a LP provider wanted to withdraw his liquidity to sell Kangals. The provider will think twice since he will also loose his reward advantage.
So maybe this can also provide stability for the price.

Other than that I think there is nothing else can be done for the impermanent loss. This is the best we can do. Great work!

1 Like

Small update on this, in 3rd step of “Scenario where the KANGAL price goes down after staking your LP tokens”, where mentioned “saved info about 20M KANGALs is ignored and your rewards are calculated with the current ratio” can lead to a flash loan attack in future, by an attacker lowering the price of KANGAL to change the ratio to get more rewards minted.

To prevent we will add an option to update the position instead, which will add a short block time limit (in seconds) to avoid potential flash loan attacks.