Two Proposed Changes to Rewards: (1) Replace LP Token Staking Rewards with DEX Yield Farm Rewards; and (2) Remove Volatility Factor from Rewards Formula
TL;DR: This Temp Check involves two suggested changes to the Indigo Protocol rewards structure. The Labs team has consulted with the Indigo Protocol Working Group on these suggested changes. The first suggestion is to replace the current LP Staking rewards feature and with DEX yield farming support (e.g., rewards to DEX users delivered on the DEX along with DEX rewards). And the second is to change the Stability Pool rewards formula to remove the volatility factor (which is a formula based on the past 365 days of an iAsset’s price to help reward).
- DEX Yield Farming: The Labs team has been monitoring the feature which enables Liquidity Provider Tokens (“LPTs”) from DEXs to be staked within the Indigo Protocol and earn INDY rewards. The initial intended benefit to the Protocol for distributing INDY rewards to staked LPTs was to incentivize deeper iAsset liquidity on DEXs. However, after reviewing the LPT staking feature since Protocol launch, that benefit did not sufficiently materialize, as has been made evident by the still-relatively low iAsset liquidity on DEXs.
In the current rewards design of the Protocol, a user must choose between staking their LPTs to the Protocol or to a DEX; this can potentially cause a user to miss out on any available triple yield farming opportunities.
We would like to propose decommissioning the LPT staking rewards feature of the Protocol, and replacing it with a feature which provides those same INDY rewards which were distributed to LPT stakers within the Protocol, and distribute them as rewards to iAsset liquidity providers on DEXs instead. The result of this change would be to make it easier for users of a DEX to access triple yield farming opportunities as to the iAssets. We suggest that the same rewards calculations be used for this proposed DEX yield farm support as was used with LPT staking.
To implement this change, Indigo Labs will, as part of its services to the Foundation, work with DEX providers which are whitelisted through the LP token program to build the infrastructure needed to allow the distribution of INDY rewards through each DEX and thereby enable access to triple-yield programs. A key step in the process will be that as each LPT farm is activated on the DEX, the LPT will no longer receive rewards through the Indigo Protocol LPT Staking program. Any transition will of course be announced ahead of time on socials and through the Discord.
- SP Rewards Volatility Factor Removal. iUSD has recently seen periods of a downside depeg that has ranged anywhere from 1%-8% under the target $1.00 peg. This is happening as a result of a spike in supply which is part of a normal ecosystem development to find the right self-stabilization incentives to achieve optimal supply and demand balance in an environment with low liquidity on DEXs and growing TVL.
One suggested response to this has been to implement a smart contract-based redemption mechanism. However, that will require an extensive upgrade of smart contracts and will be designed further and implemented as part of the Services Agreement work.
As an alternative step until any redemption mechanism could be adopted, we suggest helping iUSD to maintain its target peg by removing the iAsset volatility factor in the current rewards formula. The iAsset volatility factor is the standard deviation of percentage differences for the 365 daily prices (prices at 00:00 UTC each day) of the underlying asset for the last year. For example, these are the volatility factor numbers for April 24th, 2023:
iUSD: 0.046
iBTC: 0.028
iETH: 0.028
The ratio of these volatility numbers is included in the SP rewards calculation as one of the three components that determines what share of the SP rewards each stability pool gets. The higher the volatility, the less INDY rewards go to the pool. The other two components being the total market cap of each iAsset and the saturation of each stability pool (what percentage of the market cap is in the SP).
The volatility factor was included in the initial rewards formula because it was assumed that highly volatile assets would get more liquidations and thus more ADA rewards, and would therefore need fewer INDY rewards to incent the same beneficial user behavior. The problem is that the rewards formula, with this volatility factor, is currently ignoring the fact that iUSD, despite having a higher volatility on paper, doesn’t get many liquidations at all. Therefore it’s under-rewarding the users staking iUSD to the iUSD Stability Pool relative to the other iAsset SPs.
If this change was to be made, the SP reward distributions for the last epoch (earned during epoch 407, distributed on April 25, 2023) would have been different as shown below:
Actual rewards:
SP reward for iBTC: 8,224
SP reward for iETH: 8,277
SP reward for iUSD: 12,266
What rewards would have been without the volatility factor:
SP reward for iBTC: 6,799
SP reward for iETH: 6,903
SP reward for iUSD: 15,065
The increased rewards to iUSD would, we believe, both help support the peg for iUSD and more correctly reward those SP users according to the actual volatility of each iAsset.
While we believe that this is a necessary change to the rewards structure, we do recognize that some volatility reduction / moderation will likely still be needed for new iAssets during their early epochs when their liquidity is just building up. We propose to address this volatility concern for each new iAssets as it is implemented based on the circumstances at the time, possibly by applying a short-term volatility factor to such new iAsset.
Please let us know your thoughts on these proposals. As always, we are happy to amend this Temp Check to address community preferences for other steps to support the Protocol and specifically the iUSD target peg.
Related to these issues, the Labs team is also working towards open source the Protocol rewards calculator. We have been working for some time on refining the formulas and code. Once we have some direction on this Temp Check and any final changes that may be needed, we will have it ready for open sourcing to the community.
