I voted for that option (if that corresponds to option 4 - not that clear to me).
- No risk for $DPI as we know it.
- Yield-seeking users will go to the farm regardless of this being an extra-step (most farmers are power-users and they can handle that type of complexity as long as there is extra yield to make).
On this post, I was thinking about creating two farming options : One for $DPI holders, one for $UNI-LP-DPIETH holders, with at least the second one generating $INDEX rewards (as otherwise existing LPs will be confused about whether or not they should “risk” locking their assets in a farm instead of staying in the origin LP staking contract).
However, another option that is also compatible with the option 4 and option 3 at the same time :
- One farm that takes $DPI as input and do all the yield stuff behind the scenes, but also return $yDPI as @Etienne and @overanalyser talked about before. That would be extremely similar to a Yearn’s vault (and can be a yearn vault as discussed before) with the benefit of having a liquid $yDPI that can be then traded on Uniswap.
- A second staking contract that takes $UNI-LP-yDPIWETH tokens a receives $INDEX at the same rate as the original staking contract (that keeps running in parallel).
Advantages of this approach :
- $DPI as a yield-generating instrument on an opt-in basis : Users do their due diligence.
- With $yDPI, we can incentivize liquidity provision (yDPI-ETH Uniswap pool) with $INDEX tokens so liquidity reaches comparable levels as for the DPI-ETH pool (as less LP in a pool will mean higher potential yield).
- Thanks to the above, users can onboard directly to $yDPI if not interested in the vanilla $DPI.
- Checking $DPI and $yDPI holders regularly can give valuable information about product-market-fit.
Cons :
- Lot of development for a complex vault (but less if we start with basic lending platforms and move slowly from there).
- $DPI and $yDPI can be seen as two distinct products, which can add confusion for newbie onboarding. However an idea would be to create $yDPI as something “external” first and see from there, how it should integrate (replace ?) the original product.