Thanks to the quality of discussion by the community in @overanalyser’s 2% Cash Grab and my earlier DPI as a productive asset post, we now have a clearer picture on the tradeoffs between various upgrades proposed by the community. This post will summarize the current state of discussions and get some further signaling prior to tomorrow’s governance call.
[EDITED 10/27 to remove implementing governance as an option and move to a separate post. Meta-governance is not within scope of making DPI productive, rather, it is an INDEX initiative]. Below is a quick summary of the 2 options currently considered by the community and the existing open questions and challenges/risks to implementing each:
Implementing yield directly into the existing DPI. Allows existing holders to generate additional yield and offset streaming fee of the DPI. Targets the persona that cares about maximizing yield opportunities in the index. Proposal here
Gain confidence that we can secure some of the potential earning for INDEX holders benefit.
Show DPI holders, that we are looking at ways to reduce AUV costs.
Double the gas for minting/redeeming Sets, compounding smart contract risk that hurts the narrative and brand of DPI being a “boring” asset, high R&D cost to implement
Adds significant risk for external DeFi derivative protocol integrations (any protocol that relies on oracles) and large exchange listing plans
Will shift DPI from a passively managed ETF to a actively managed mutual fund, as Santiago mentions here
Additional smart contract / security risk will turn off the “boring” persona that just want safe and passive exposure to DeFi and not care about 1-2% extra APY
Launching a new DeFi Accumulator Index that is more experimental by nature, and actively seeks yield. As it is an actively managed product, this Set could allow for staking in SNX, staking in KNC, staking directly in YFI etc. Targets the persona that cares about maximizing yield opportunities, while allows the “boring” personas to continue to hold the safe, vanilla DPI Set. Proposal here
This is more experimental by nature, and actively seeks yield
As it is an actively managed product, this Set could allow for staking in SNX, staking in KNC, staking directly in YFI etc.
Targets the persona that cares about maximizing yield opportunities, while allows the “boring” personas to continue to hold the safe, vanilla DPI Set.
Cannibalization with existing DPI growth as it is a separate product
High technical cost to implement, double gas cost to mint/redeem
A 3rd Option
Based on the feedback discussed above, I think there is a 4th option below that the community can consider which hopefully bridges some of the concerns above. The important considerations here are:
Separate concerns for the risk seeking DPI holders and the “boring” DPI holders that just want a vanilla passive exposure
Minimize cannibalization of DPI
Further DPI as a “primitive” in DeFi
This will be an ongoing draft so please comment!
The 3rd option is: launch a separate DPI Yield Farm Set run by the coop that accepts DPI as collateral. This will be setup similarly to TokenSets’ Yield Farm Sets. It would be built on top of the DPI, which further pushes the narrative of DPI becoming a “primitive” (similar to how WBTC or DAI is a primitive)
How it works
User deposits DPI
Strategy automatically redeems DPI into underlying tokens
These underlying tokens are then sent to AAVE, Compound, or staked in native protocols to earn yield (e.g. SNX, KNC, YFI staking)
Periodically buy back / mint DPI with the yield earned, so the DPI Yield Farm holders will
Eventually, with an integration of lending protocol, the DPI Yield Farm strategy can shift to borrow stablecoins to farm yield used to yield more DPI
Makes DPI productive without diverting liquidity from DPI (DPI LPs on AMMs will still have to choose between providing liquidity and generating yield using this strategy)
Run experiment outside of DPI, and does not hurt our position, brand and narrative in the market
Existing product is being used. Goal is still getting to @overanalyser’s 1% goal for the DPI, while solving the cannibalization concern
Does not farm INDEX
Doesn’t compound yield for DPI/ETH LPs in Uniswap
Highest technical cost
[UPDATED 10/27, Option 1 is not within scope of making DPI productive and will be moved to a separate post. Please do not select Option 1 going forward]
I’d rather for the DPI token to be naturally productive.
Option #4 doesn’t really make DPI productive without diverting liquidity. As a LP, I definitely want my DPI to be productive while I’m providing liquidity. Being an LP is all about yield, and even better if you’re earning yield on the underlying tokens.
Now that all the different things we’ve been talking about are laid out together with all the different conversations it makes me think we don’t actually know what is most useful at all.
Can we do none of them? I personally haven’t heard actual DPI users calling for any of these, only INDEX people. We already have a strong value prop as is, we could hold off until BD and marketing efforts start bearing fruit (DPI on Aave, more whale accounts , etc.) and wait to hear what users actually want.
That being said #1 is the only one that most directly benefits INDEX > DPI holders. It gives us leverage to make moves in the space, build brand, and create network effects without investing into risky product development.
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.
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.
This. Whatever we end up doing it will be invaluable to test the waters and see where the demand is. There is so little data about Indexes in crypto at this point that I think the cannibalism argument really isn’t that strong. If a certain approach draws in more users from somewhere else, doesn’t that tell us we should be focusing our efforts there instead?
I personally voted for option 4 (which I think is the same as what neozaru is referencing, it’s not clear in the OP) but I think we have an opportunity here to experiment and capture data while the space is still growing so doing any of these options will be beneficial.
I see one issue with all the solutions proposing to use the underlying tokens: how do we make sure that we will end up following the monthly rebalancing system ? Should it be part of the yield farm strategy ? Furthermore, is it technically possible to not redeem the DPI once it’s in the yield farm so that we do not reduce the TVL ?
@Etienne For your second question, in this proposal, staking $DPI in the “Yield Farm” locks your $DPI in the smart-contract and gives you are $yDPI in return. This $yDPI is non-redeemable : You need either to unstake from the “Yield Farm” (meaning giving back you $yDPI for $DPI and then redeeming the $DPI), or trade your $yDPI for something else on Uniswap hence the idea of expanding the Liquidity Incentive program to $yDPI/ETH.
I noticed that TokenSets farms are also not mintable nor redeemable, only tradeable, so even an introduction of $yDPI in TokenFarms wouldn’t break the design (just a little bit harder to read from a marketing perspective if you have an index called $DPI and a farm called $yDPI).
For the first question about ensuring rebalancing while tokens are farming, I think it depends on the underlying protocol that is used. If we assume that we start with Aave and Compound and that we don’t occupy most of the liquidity (meaning we can withdraw and re-deposit everything), I think it is easy to do aUNI -> UNI rebalance, then back to UNI -> aUNI. Not sure about the technicals, but I think flashloans might be used to put some DAI collateral buffer, withdraw the tokens, swap the tokens, re-deposit the tokens, withdraw the DAI collateral buffer, repay the flashloan. All in one transaction. We’d need an smart-contract expert to tell us if that is possible though, and things might not be as simple (but I do think we can think of a design that is simple even though doesn’t maximize yield to 100% of its capacity)
The top half describes the current system. All the underlying tokens are locked into a single contract( Currently worth 220,000 DPI) and external users interact via the issue and redemption contracts. These contracts look at the ratio of tokens within the DPI treasury and add / remove in the same ratios. I would expect no change in the operation, nor gas costs for external users.
The governance contact has permission to add and remove tokens to rebalance and collect fees.
The INDEX coop direct the governance contract to split the DPI treasury into 2 parts (lets assume 50:50), so that both contracts (treasury and farm) contain the tokens in the same proportions (Market cap weighed). The Treasury has to be large enough so that it can cope with any surge in redemptions.
We can then take tokens out of the farm treasury and us that to collect income. These should be secure protocols with liquidity (and minimal timelocks).
Rebalanecing happens once a month. The treasury needs to be done quickly (as at the moment) the farm can be done short later (on one external interacts with it, so it just needs to be done before we return the farm to the treasury). The rebalance will require more work than the standard one as there are two pools to be adjusted (with one containing cXXX and aYYY etc).
This approach makes the $DPI treasury look identical to external observers / traders. We would need to tweak the AUV calculation, but that just needs to look at 2 addresses rather than 1.
Some comments on the other approaches:
I don’t want to force the holders to make any decisions (hold, stake, buy a second index fund).
I don’t want hoders to stake PDI as collateral with INDEX, when they could use it as collateral in other protocols. - We should be capturing value with inimial inconvenience for our customers / others.
If we launch a yDPI vault that contains aCOMP, cAAVY, govYFI. We force the direct purchaser (arb bots) to interact with the other contracts. That makes it more expensive. so buying / arbitration is disfavoured.
Also if we launch yDPI/ DPIacc, and specify cAAVE, what happens when we find that yAAVE is a better idea? We have to change our issue and redemption contracts, and any arbitration bots have to be rewritten.
The 2 pool approach also allows us to put part (maybe 10% ) of the DPI treasury into longer term time locked opportunities. Something that doesn’t work with yDPI which would likely be all or nothing.
Asking users to deposit DPI which we then farm from a vault by splitting is something that anyone could do (So we could see a yearn DPI vault with a strategy DPI --> YFI, AAVE, COMP… --> gov,YFI, cAAVE, aCOMP…). Yearn may be able to do it better than we could (direct links to MKR oracles…).
However, deposit and redeem DPI would impact the DPI AUV, which is something we are trying to grow. This reduces the rate of adoption of DPI by others and it would impact INDEXcoop streaming fees from DPI. Personally, I would consider such a vault to be a vampire attack on INDEX.
I want other protocols to build DPI into their systems, but as collateral, not something to be broken up.
As we control the smart contracts, WE are the only people who can do something like the approach I outlined in the 2% cash grab. A similar approach doesn’t work with balancer pools.
I guess the original idea is to have a generic vault and then having governance being able to assign dynamically which tokens goes where. But maybe that would be even more complicated technically.
I totally agree with this. In my idea the only part that must be up to IndexCoop is the LP incentive part. It is true that for the rest, anyone could build it. Doesn’t mean IndexCoop couldn’t though, as it could have an index-governed dynamic strategy of some sort (?).
They sound to me like the most important differences between the two ideas : Is it mostly a debate between (1) leaving the choice to $DPI holders (creating friction, but opt-in-ing the risk) vs. (2) doing it transparently for them (no friction, risk shared with all $DPI holders) ? I just want to find out where is the point of disagreement.
To me, the most problematic points with (2) are :
Yield risks (KNC voting contract, Aave/Compound smart-contracts). That could be hedged with some type of smart-contract insurance products (that would be automatically purchased) such as Nexus Mutual, but would also lower the yield, and increase complexity.
Mass exit : How do you handle the case where everyone wants their $DPI redeemed at the same time ? Having 80% of the capital moving in a few days is not something uncommon in DeFi (if that is a point of disagreement I can try to do some research to fact-check this statement). If you put “only” 20% of the $DPI to work, it also means you are getting - at best - 20% of the optimal performance.
Just to clarify, I am not totally set with a solution or another, and I actually very much like the original idea because it makes $DPI even more attractive and no-brainer entry point for people wanting to be exposed to DeFi. However there are risks I don’t see solution for. I’d be happy to change my mind through discussion and new ideas.
Hey OA !
In my opinion, a yield farming vault is an automated (and less governance intensive) way of doing what you propose. The only difference is that, with the vault, there is no liquidity crisis possible, 100% of the committed funds are in use (more profitable for end users compared to 50%), and there is NO room for potential Index Coop fund mis management issues : a user sees a smart contract vault, assess the risk/reward ratio, and decides to opt-in or not. DeFi is all about letting end users decide by themselves.
Definitely an open question currently. We do have some evidence that making it internally productive might actually reduce its odds of being considered a security because people will be holding the asset for more than just price speculation.