Request for Discussion: Activate Intrinsic Productivity (IP) for DPI as a Standalone Product

This is definitely one of the most interesting forum threads I’ve seen! Really good discussion and expertise.

Adding my 2cents:
As much as I would like to see IP for DPI, reading all the risks associated with it combined with the effort and revenue potential, also raises concerns whether this is the right approach.
But as mentioned a few times above, I have high hopes for the “vault solution”. Isn’t this the silver bullet to our problem, as we don’t have to touch $DPI, but we can offer a way to activate IP?
Plus, since it’s an opt-in solution, making it easier to inform users about risks, we could probably also implement strategies that might have a higher risk/ longer lock-up periods (e.g. activating REN → see here).

5 Likes

First off, great work by @Thomas_Hepner and @Kiba putting in the groundwork and presenting these ideas. From what we already know and outlined again from @oneski22 's points is that there is a risk that implementing IP directly to DPI may jeopardize its investability leaving us with option 2 or some version of it.

I would just like to point out that there could well be a situation whereby institutions could lend their vanilla DPI through the defi market “legally” picking up a bit of yield. The defi native market could then borrow that and deposit it in the vault strategy to arb any additional yield. (Effectively a carry trade). We are probably some time away from this but this “regulatory arbitrage” is very common in tradfi. I believe we should be mindful of such future opportunities.

As @Lavi points out the vault strategy seems to be the silver bullet so keen to hear what the potential downsides are to this specific strategy.

5 Likes

Hi All,

I really like the idea of optimising how we utilise the tokens within DPI to generate additional returns. I am a big fan of this.

I have been pondering how to do this for while now and I keep coming back to the thought - Why pass on IP benefits to holders with our left hand and then takes fees from users with our right hand. If I am reading this right DPI generates 95bps fee revenue and with this proposal, DPI would give to holders 50bps. Holders essentially pay 45bps fee whilst DPI still generates 95bps.

I believe @LemonadeAlpha has done some interviews/research that indicates our holders are no particularly sensitive to the stream fee. With that in mind, I would be reluctant to think passing this IP onto holders is going to make any difference.

50bps in DeFi isn’t going to get people excited. It is nice, but really I don’t think it is sufficiently large enough to move the dial in terms of generating more units of supply.

I would however do IP and put the proceeds in our own back pocket. We can make some extra income on top of the streaming fees, that would be great for INDEX holders. I would rather see Index Coop implement some level of IP and think of it as a way to boost our income and the profitability of the product. This would enhance our margins, profitability and I don’t think it will impede any of the extrinsic use cases being looked at.

I think we can explore IP and think of it as a way to bolster our profit margins on the product.

3 Likes

So the problem with the vault model AFAIK with the way Set Protocol works is that the assets still come from the main DPI vault so there are no “user funds” it’s all DPI, so all DPI holders are exposed to risk you’re just giving rewards to the “opt-in” stakers but then everyone is incentivized to stake so there is no vanilla DPI or vanilla DPI holders have disproportionate risk/reward.

If you want to remove the assets in the vault from DPI then that’s a two product solution because we’re taking AUM from DPI and need another rebalancing operation.

3 Likes

@oneski22 @Metfanmike @Lavi @MrMadila Please see Kiba’s comment for why the vault model is not a feasible third option.

@richard @puniaviision Do you agree with @Kiba from a technical/implementation standpoint about the vault model?

1 Like

adding DPI to the iDPI vault (which is what I am temp calling it) would be a redeem operation [or the vault could hold a reserve of DPI, and unwrap prior to using strategies], moving the underlying from DPI to the iDPI vault), a withdraw remints DPI (swapping if needed to get the balance right) [or pulls from reserves].

This creates a firewall between the two. iDPI holders bear all risk of IP. DPI is protected. Legally and additional smart contract risk due to IP strats.

As for @Matthew_Graham’s point for getting revenue from this, we could again take the yearn model of 2% management fee and 20% performance fee for the vault.

4 Likes

@oneski22 @Metfanmike @Lavi @MrMadila @Matthew_Graham @fallow8 @trx314 @Kiba

Thank you all for your thoughtful commentary - the community sentiment polls are now live!

Edit for Clarification Purposes: The “vault model” described in the comments would be a subset of the two product approach (options 1a and 2a.). The vault model is intentionally not included in the voted as it needs to be vetted among other technical implementation options from an engineering perspective.

1 Like

Re a middle way vault style model.

In the past we have discussed the idea of allowing users to stake DPI, in return for receiving income from IP. here and here.

The staking makes it purely opt in, and allows only the tokens underlying the staked DPI to be farmed (but we can farm 100% of those), So it does solve a number of problems.

However, there are downsides:

  1. DPI holders will need to pay gas to stake / unstake - we are making holder become more active
  2. DPI holders will need to stake (likely time blocks > 30 days) or with a cool down period.
  3. Eng resources will be required to do the IP, staking contracts, possibly rebalances, calculate the share of income.
  4. Extrinsic productivity (Cream, AAVE, Alpha) isn’t available for staked DPI.
  5. IP on DPI just isn’t that large - how long do you need to stake to cover gas?

PieDAO DeFi+L share their IP data for a similar product:

To me, such approach is a lot of work, and isn’t likely to move the needle for coop AUM. So, the discusisons with @Thomas_Hepner and @Kiba came down to a single product with IP, or two separate products. (as the original post above)

4 Likes

Would be nice to have a voting option for those who still think we should not be moving forward with IP for DPI.

3 Likes

would have been nice to include, seems the question is more “if we are going to do IP, which method should we do”

Agreed. Without asking that additional question, one would likely conclude that the results indicate clear community support for moving forward now with IP and that it’s more a question of which proposed IP path is preferred. I selected the two-product approach because it’s the lesser of (what I see as) two problematic paths, not because I believe we need to launch a solution today.

That said, if the thought process here is to gauge community sentiment on the preferred IP approach and then put that to a separate vote - “Do we do this IP approach today or should we hold off for now?” - then this might be an unwarranted concern.

Is that the thinking, @Thomas_Hepner?

@Metfanmike @oneski22 Apologies for the delayed response to your comments - I was out sick the whole weekend.

The intention of this governance post was to gauge community sentiment for which version of IP should be implemented (one product vs. two product approach), if/when IP for DPI is prioritized. I do not think there is clear community support to move forward with IP now ahead of all other priorities.

Per @puniaviision , prioritization is determined by a Work Team Analysis after DG1 vote before moving to a DG2 vote.

@Metfanmike @oneski22 Does this address the concerns you both raised in your most recent comments?

Community member/DPI holder here, but looking to contribute more substantially.

Love all the thoughts here. In a vacuum I’d have preference for a single DPI that includes IP because it would be good to not fracture liquidity between the two, but it sounds like like the IP would hurt the ability to get DPI listen on CEXs and that is reason enough to keep them separate imo.

For those not in CEXs, my guess is that almost everyone would prefer to hold iDPI over DPI. I’m no whale, but DPI is my second biggest holding (after ETH) and I am doing ETH-DPI LP with leverage through alpha homora v2 with all of my DPI. If there were an iDPI and an index incentivized pool on Uniswap like there is for DPI, I would switch my position tomorrow.

My view on priority: High. I think I’m a minority on this, but this would be a major improvement to what I view as the Index Coop’s most important product. I get there are many other priorities to compete with, so if there is any way I can help do some of the lifting here to make it happy I’d love to pitch in. I’m not a smart contract engineer, but would love to help whatever other way I can. And if I need to learn Solidity to help, I’ve been wanting to do that anyway.

On BDI -

I think there are a few factors on why BDI hasn’t taken off.

  1. Trust. Index Coop is more well established and was wise to partner with Set Protocol and DeFi Pulse on this, in my opinion.

  2. Awareness. At least in my circle, DPI is well known and held by most, but I only know a few people who have even heard of BDI.

  3. Integrations. I’m very active in the Alpha Homora community and am much more likely to support projects that I can do leveraged yield farming with. I think that’s true for others too.

I think it would be really good to recognize the smart things that Index Coop competitors are doing and adopt them quickly rather than assuming they must not be that great given DPI remains more dominant. As a whole, I think that will help keep Index Coop from being disrupted by a competitor.

3 Likes

Welcome to the Index Coop community and thank you for the very thoughtful comment, @rshipp!

Definitely agree with you comment in regards to why BDI has not taken off and think we should learn from what our competitors are doing as well.

1 Like

yes - thank you, @Thomas_Hepner!

1 Like