Intrinsic DPI Productivity w/ $INDEX as Risk Backstop

My initial thoughts is that it sounds good. To be honest, I’ve not really been thinking about INDEX tokenomics, as I’ve been more interested in DPI.

I currently imagine something like.

  1. INDEX holders stake (with a lock in)
  2. We slowly add intrinsic productivity measure (stakingYFI, aAAVE etc…) using a portion of the PDI treasury (as per my earlier posts).
  3. Intrinsic income (less gas cost) is split between INDEX stakers and coop treasury (Split TBC)
  4. In the event of failures, staked INDEX is slashed and sold to make DPI treasury whole. I would possibly have an upper cap on this, say 50% slashing. Additional losses would be compensated by coop treasury and reserves.
  5. In the event of liquidity failure, INDEX stakers get slashed a set proportion (50% ???) I’m not sure how we would use the slashed tokens, possibly add it to the $DPI treasury as a bonus for DPI holders (who were the only people to be impacted by the DPI liquidity crunch).

I see a couple of benefits; income on staked INDEX creates a reason to hold INDEX, income to coop treasury may allow us to offset some of the streaming costs to DPI holders.

Currently, I’m not sure about staking DPI. I would like to think there are other ways that holders can use DPI (Maker vault, cDPI etc) that produce better extrinsic productivity [and do so without costing the coop anything]. However, I do like the idea of having some DPI under a time lock.

However, locking DPI for INDEX could be a good way to distribute INDEX into the community.

I do think this idea is worth pursuing further on the DPI product side. Redemption risk is the biggest barrier / concern to adding intrinsically productivity. Having a program in place first that locks staked DPI for 6 months / 1 year in place can reduce redemption risk to 0 given that the % AUV pursuing yield is always less than % locked in the contract. It also adds the ability for DPI constituents to be staked in native programs that lock up tokens for a period of time such as SNX, stAAVE, KNC etc, as long as the modules return the underlying to the DPI before the locking period expires.

Previously, the concern around @overanalyser 's 2% cash grab is that all DPI holders are exposed to the same redemption / liquidity risk through lending constituents and without a proper economic analysis, there wouldn’t be an optimal way to price what % of DPI assets should be staked elsewhere. By having an opt in locking mechanism, this segregates the risk of those who want a vanilla / redeemable DPI vs those who are in DPI for the long term (and of course there should be INDEX incentives associated to incentivize locking DPI to start).

Compared to the DPI yield farm, which is 2 separate products to segregate risk for customers, this is basically one DPI split into “sub-accounts” that segregate risk for customers.


I think this is a great way to start as it addresses three of our current goals:

  • Maximise DPI AUV - holders are incentivised by Index rewards and retained thru staking
  • Make DPI productive - allows holders to put the token to work effectively
  • Increase distribution of $Index

It also goes someway to addressing Etienne’s concerns, in that the amount staked will likely grow over time, so while it starts out as an experiment it doesn’t affect the full AUV of DPI and holders are rewarded for taking the risk with the $index yield.


So DPI is locked long term to give us a known long-term AUV to generate income from.

Locked DPI gets a share of the DPI income, or INDEX, or some of both? DPI holders risk long term exposure to DPI value.


INDEX stakers risk INDEX slashing if we loose capital due to poor choice of income generation.

I can see how that would work.

I worry that we wouldn’t get a high proportion of DPI staked as there are other extrinsic uses that complete (uniswap liquidity, cream, y vaults, Maker vaults etc). However it could give allow us 6 moths of locked in AUV to do a proof of concept. In time we would gain a better understanding of how much AUV is sticky.


It’s a good idea but it has the same issue as MKR. We would be selling INDEX at the lowest prices after a major crises so it’s terrible for stakers and Coop treasury. The big difference is this function is critical to MKR system where as for us we would be opting in to a very bad structure. Also the staking function only exposes a few coop members to risk when all coop members are responsible for the decisions that got us there. There might be incentives to stake but it introduces a freeloader problem which isn’t ideal.

We can siphon 10-25% of all Coop fees to a SAFU fund which should be able to cover any losses given enough time to build up. These index tokens would obviously be lower value because some of the underlying tokens are gone but that’s the same problem as INDEX without doing a firesale on governance power.

Using the treasury to buy insurance (not cover on NXM, actual insurance) is the best option since we have more concrete numbers to run and puts it on Coop balance sheet instead of individual members so it’s easier to account for and coordinate risk across all our products. DPI yields might have much higher risk than CGCI but we can’t segment and hedge each index’s risk individually with this backstop model. If we get a quote saying DPI will cost us 5x more to insure than CGCI then that’s a good data point to readjust our activities because it’s obviously not “boring” anymore and insurance might cost more than the yield we receive. Obviously there isn’t a protocol option at the moment and we don’t have the funds but insurance > staking in my opinion.

Locking DPI and giving them a bigger share of yield is good idea but I think we should move that to a different post.

I think this covers the failure risk in terms of if one of the farming techniques falls over. A combination of slashing staked INDEX, a coop reserve (held as ETH or DPI?), and a final fall back on INDEX reserves (built with a proportion of the farming income. INDEX holders can stake for income, or be the final backstop in case of failure. If you don’t think the slashing risk is worthwhile due to selection of farming approaches, you don;t have to stake.
I think I need to look at the AAVE staking system again as I think it’s similar.

I think that there will be some long term sticky DPI holders which we could farm. However, I agree that this is an untested assumption, and produces a liquidity risk. So staking DPI for a share of the farming rewards makes sense (at least until we gain confidence in DPI holding behavior).

The downside I see to staking DPI, is that we block other opportunities for holders to access other extrinsic productivity. (i.e. they can not stake and be a ETH-DPI LP, or use AAVE or Compound vaults etc). One way around this would be to allow different staking options:

  • $DPI,
  • $aDPI,
  • $cDPI,
  • ETH:DPI LP tokens.

Obviously aDPI and cDPI still have some liquidity in the market as people can borrow and redeem. So we may want to only remove a proportion of those locked tokens from the main DPI treasury and offer a lower reward to people staking $DPI.

I must say the AAVE safety module looks very nice:

AAVE lock in for 10 days after witdraw request
AAVE staked are placed in 80:20 balancer pool with ETH to maintain AAVE liquidity in the market.
AAVE stakers loss capped at 30%.
Back stop module containing ETH (which is rewarded) to act as buyer of last resort if AAVE auction is required.

1 Like

Hi Owls - lots of good ideas here. Adding a few thoughts:

Here’s how I see the most important priorities for DPI and Index (in ranked order):

  1. Distribution: DPI may be the best exposure to DeFi. Expanding distribution and partnerships will be essential when capital wants to get exposure to DeFi (listing in primary exchanges?). Optimizing for productivity is enticing (for DeFi natives), but less so for the majority (I suspect). It introduces a level of complexity that can hurt composability and add more risk (i.e., exchanges may shy away if a large % of DPI assets are locked in yield-maximizing strategies, which makes the case for having a second DPI - but that fragments liquidity). Open to ideas here…(and know it’s been discussed in other threads)…
    2. Index<>DPI Value Accrual: as proposed by others, if DPI is earning yield, then some % of rewards can be diverted to INDEX holders and/or DPI stakers (if you stake DPI you earn INDEX; the longer you hold DPI and INDEX the more rewards you’re entitled to). Naturally, this would match the duration of the DPI portfolio and minimize the risk of redemptions > liquid assets. The risk of having this strategy is that it makes DPI somewhat less attractive for not active users (perhaps they turn to another more plain vanilla index product). I suspect there is a much wider audience that is looking to get exposure to DeFi and less concerned about maximizing yield. The tradeoff here is (1) expanding DPI distribution (#1 above) vs. optimizing yield (#2). Perhaps the most straightforward and safest strategy is to start with a small % of DPI assets and safer strategies (ex- YFI, AAVE, SNX staking), and then grow from there as we get more data on the avg. holding period among DPI holders.

As for the rationale to own INDEX, I think that as DPI grows, so will the interest in holding INDEX, especially among DeFi projects. For instance, should Augur be there? Why not others? While the market cap methodology restricts this to a subset of DeFi projects, some are eligible but not currently included.

As I see it, the vision is for INDEX to become what exchange listings fees were in the 2017-era. If you’re a DeFi project wanting to get traction, then being included in DPI (or some other INDEX co-op set) becomes essential. The missing link right now is the low liquidity of INDEX. Perhaps we can divert some INDEX rewards to UNI-LP providers? @setoshi et al.


Hello @srs-parafi, and welcome to the discussions. There are certainly lots of ideas on the go.

I think that if we restrict the intrinsic productivity (e.g aAAVE, cSNX etc) to the proportion of the $DPI we have staked within a coop contract, then we should ensure 100% redemption liquidity.

I agree that many of DPI holders are not bothered about yield, but there are some that see the 0.95% streaming fee as to expensive, so for some customers a low yield to offset the fee may be attractive.

I see a time when projects will be very keen to be included in out funds, thankfully, we have DeFi pulse as an independent gate keeper on that aspect, so we won’t see any flash loans to get added to an index…

I think the rational to not incentivise the INDEX ETH pool, as to avoid the impression that we were trying to pump the INDEX price. It’s possible that as we will soon have 10% of the INDEX tokens in circulation, that rewarding the pool won’t pump the price.

I was reading the AAVE safety module stuff earlier. I found the use of staked AAVE to fill a 80:20 balancer pool to be an interesting approach. Staked AAVE becomes AAVE liquidity in return for some divergence risk and Balancer rewards.


To add a few thoughts:

  • Getting distribution is 100% the goal. Based on my current conversations w/ exchanges/platforms, my current feeling is that intrinsic productivity may have less of a factor to composability / listings than we may think and doesn’t increase the risk of getting added that much. IMO, the best example to the DPI system is DAI - where risk must be managed, and has not deterred listings or usage more broadly as a stablecoin. Perhaps, what we need to do is a deeper thread to analyze more closely how this can affect distribution based on various conversations we’ve had.
  • Re: Intrinsic Productivity, the nice thing for normal users is that it lowers the net-streaming fee for end users (which is definitely something they would want / be interested in). And more active users can opt-in to maximize yield if they choose to lock their DPI.

I really like the idea @overanalyser provided that stakers of $INDEX have their $INDEX added to a liquidity pool - which solves for liquidity AND backstop.


I don’t think looking at AAVE and MKR are good examples because they are banks and have to secure user deposits where as we are an investment vehicle that is meant to be risky for higher returns. We definitely should insure indexes against actions we take but I don’t think that INDEX staking is the best way, using our governance token in that way doesn’t seem totally aligned to our business model to me. Also if we want to be truly “boring” we should be eliminating all risks up front versus having a fallback system that might not even work if worse comes to worse.

Assuming we had multiple indices and we use them all as collateral would make a bit more sense. For examples anyone can deposit DPI, MVI, CGCI, etc into a balancer pool like AAVE’s and they get part of Coop fees which are paid in index tokens so we just airdrop liquidity into the pool. If one index lost some tokens, it’s loss is capped at the percentage of it’s weight which the pool would rebalance to stabilize price automatically and then we sell off the rest of the index tokens to buy back the component token that was lost.


In terms of risk progression, my generally philosophy is we take baby steps to ensure we understand the risks / returns along the way. It could look like the following from low-risk to highest risk:

  1. Non-Staking Governance: Voting on Uniswap and Compound. No principal risk. No redemption risk.
  2. Non-Principal Risk Staking: Stake on Kyber/YFI to participate in voting or SNX staking. This level should not have any principal risk, but can lock up tokens for a period of time.
  3. Lending Protocols: Examples include lending on Compound/Aave for interest. Principal risk, but it should be initially be covered by Aave/Compound’s insurance funds and also $INDEX funds. Redemption Risk.
  4. Staking with Principal Risk: Stake AAVE on Aave (where you can lose principal). This incurs principal risk and may be covered by $INDEX and/or purchased insurance.
  5. Leveraged Farming: Take DeFi token, put as collateral on lending protocol, draw DAI, and farm with it. This is the highest form of principal risk as it involves leverage.

In each of these progressions, we start with the least risk and slowly move our way up only after fully understanding the risk / reward tradeoffs. The progressions of 1-3 should be quite straightforward. 4-5 represent the biggest leap.

1 Like

If we do our jobs in terms of risk management correctly, then staked INDEX / Stability reserves / INDEX reserves will never be required.

However, staking INDEX serves a number of purposes:

  • It forces longer term engagement with the protocol - Just holding gets less / no rewards
  • It provides a backstop in case we screw up
  • It demonstrates to other protocols that we are being responsible / cautious.
  • It gives us a “reason” / mechanism to reward INDEX holders. The alternatives are to airdrop onto holders (continually? ) or a buy and burn model (which seems pointless when we still have ~60% of INDEX in the treasury).
    *A longer fixed lock in allows us to run a fixed length experiment on intrinsic productivity. Trying to manage a rolling lockup (which I think AAVE are doing with 10 day cool down on withdraws) sounds much more complex to implement.
  • A method to identify people with long term views on INDEX (ie. people to favour with more distribution)

I’m leaning towards three or four ~90 day locking running in parallel:

  1. $DPI Vault
  2. DPI:ETH uniswap pool Vault.
  3. INDEX token Vault.
  4. INDEX:ETH uniswap vault

I would say that all three should receive a combination of INDEX and income from the intrinsic DPI productivity.

Fixed term lockups, make it easier to manage. We can deploy, hold and then unwind the farm to a known schedule. Then calculate the gains and allocate the rewards before the end of the lockup. Trying to continually issue rewards sounds like a nightmare to me.

The schedule for releasing INDEX needs to be considered, as dropping lots at once will impact the price (See BOND). I see a few options:

  1. Release all the reward INDEX at the end of staking (as per the DPI rewards ) - risks massive price drop right at the end of the 90 days.
  2. Release INDEX to be claimed per block as is done currently with the liquidity - Allows stakers to release and sell as and when they wish.
  3. Lock the DPI vaults a week before the INDEX vault, and issue INDEX to DPI and LP pool stakers then the vault is locked. This creates a rapid increase supply of INDEX and likely pushes the price down. However, some DPI stakers may immediately stake the INDEX. In addition, it provides an ideal buying opportunity for people who want to Stake INDEX.

Things I fully agree on :

  • $INDEX staking for covering failure risk.
  • $INDEX staking mixed with LP incentive (Balancer pool).

What I am less sure about :

  • 90 days lock up to get more APY while mitigating the liquidity / redemption risk.
    –> 90 days sounds a bit long to me psychologically. I’d rather have shorter renewable locking periods (but maybe it is just a number given as example).
    –> But a rolling lockup/unlock for $DPI staking sounds like a good idea (less frightening for the user and mass-redeem more predictable).
    –> I’d like to first define at which step (on the @setosh’s risk scale) we’d start in order to evaluate first what is the redemption risk. I’d go for starting at step 2 (Non-staking governancce + non-principal risk staking) in which case it would be about evaluating the redemption risk of funds deposited on Compound and Aave. Maybe it is possible to build different scenario to evaluate the risks and what proprtion of $DPI would need to be staked to mitigate this risk.
    –> Bonus : Some inspiration from Loopring staking : You start earning rewards on the base of the tokens that have been locked for 90 days. After 90 days, your tokens are unlocked, but since you continue accruing fees, that’s an incentive to keep your tokens locked. With staked $DPI we could imagine a system where rewards are not accrued before a certain period, so you could unstake whenever (?) but you would not get any reward before xx days. Once you start accruing your rewards, you want to keep your token staked as it will be continuous. It doesn’t solve the mass-redemption problem, but the rewards that are not accrued during the first xx days can be redirected to a reserve that mitigates the mass-redemption risk (and the reserve would be proportional to the number of $DPI staked).
1 Like

90 days was pulled out of the air. Some earlier comments said 6 or 12 months which feels to long to me. One of my older posts proposed a 1 month period (between rebalencings) to make it simpler to implement.

Long term some form of rolling locking / withdraw period makes sense. I think that needs continual collection and distribution of income which sounds difficult to me. I think that using a fixed time period vault (for DPI at least) makes implementation much simpler.

I would say continual income generation and distribution requires something like a fully automated Yearn 2v vault with the associated coding and testing overhead. While a fixed period looks closer to the vault rebalnce process:

  1. Move Tokens from DPI treasury to DPI farm
  2. Move Tokens to income strategies
  3. Wait 25 days to generate income
  4. Unwind farms
  5. Calculate and distribute rewards
  6. return initial tokens to DPI treasury

I think that this would be something much easier to implement.

Then once we have proven the concept we can look at improvements to the scheme.

Yes a longer lock in will put many DPI and INDEX holders off. However, I think for an initial experiment / proof of concept we will get some locked in assets to work with.

Just to add my two sats.

I’m still all for the $DPI staking, seems like a no brainer. I don’t agree with staking $index if it’s only going to be used as a backstop and stakers are rewarded with more index tokens.

If you look at what Yearn have gone through recently and their proposed changes for V2 vaults, they are working to align incentives across contributors, strategists/devs and token holders/governance. One way they are doing this is by changing the whole fee/reward system to use YFI rather than yUSD. It aligns all participants toward making sure the protocol is successful without taking excessive risk, as all rewards will be based on YFI’s price. The added bonus is a small but constant buy pressure on the token.

If you compare that to a token like mStable’s MTA, where it acts as a backstop for stablecoins de-pegging and stakers are rewarded with more of the token, there is not a great deal of incentive to do anything other than farm and dump, this has destroyed the price and thus incentive creating a doom loop for the token.

This relates to Index in that, we can have a massive treasury of Index which become useless if the price of the token drops drastically. So while we haven’t been focused on the price until now, it needs to be propped up to make our index tokens useful, to encourage market buyers, to support token holders who want to govern and to make contributors rewards worthwhile.

So I’d suggest if we do $Index staking, there is a three pronged approach to where the value generated by Index Coop goes:

  1. A portion of streaming fees from DPI (and future products) paid to stakers, perhaps in the product token to begin with (so DPI) which should keep it in the ecosystem and provides small but steady yield
  2. The remainder of streaming fees sent to the treasury which increases the value of the protocol as a whole (used for contributor rewards, future incentives, other overheads)
  3. Yield in the form of $index rewarded to stakers for taking on risk as a backstop

Just proposing $index become a risk backstop and rewarding stakers with more $index is a recipe for destroying token price and totally changes the dynamic of the protocol. This has a knock on effect of reducing the value of any treasury we do build up, and could stunt index coop’s growth. I will take a look at how AAVE have approached it as they seem to be fairly successful, just think we should think carefully before changing a fundamental tenet of the governance token.


That makes sense. Part of the streaming fee should be used to provide returns for INDEX holders / stakers. And by mixing the income streams for INDEX stakers / coop treasury we demonstrate multiple income streams for each.

I see three sources of value:

  1. Strategic reserve (INDEX),
  2. Staked $DPI intrinsic income from farming
  3. Streaming fees

And a few worthwhile places to apply it:

  1. $DPI stakers (I would suggest $INDEX and $PDI from intrinsic income)
  2. DPI-ETH liquidity providers (I would suggest $INDEX and $PDI from intrinsic income)
  3. INDEX stakers (I would suggest, $INDEX, $DPI from intrinsic income, and $DPI from steaming fees)
  4. Coop treasury (I would suggest $DPI from intrinsic income, and $DPI from steaming fees)
  5. Coop operational expenses (community rewards, etc) - I would suggest INDEX for community rewards and sale of DPI from treasury for other expenses.

We could also consider INDEX : ETH liquidity providers. This could be done by incentivising a pool via INDEX, or but the coop treasury seeding a pool with INDEX and ETH (using streamed DPI to buy ETH?).

The fun part is deciding on the splits…

1 Like

As we get into the weeds I think we’re getting what’s good for DPI as a product and good for Index as a platform mixed together. I know it’s hard to differentiate sometimes but I think it has a big impact on what reward structures should be. E.g. $INDEX as a backstop is platform level and should be rewarded with $INDEX where as staking $DPI to earn yields is product level and should probably only be earning more $DPI and not $INDEX.

In general I think we are on the right track. I don’t agree with $INDEX strategic reserve but I’m not opposed to it either. I do think longer lockups are better since we have a longterm product but we can do conviction voting type setup where you can choose length of lockup and get proportionately more rewards.

It would be interesting to layer governance into this backstop mechanism e.g. you stake specifically to $DPI not all indexes at once and receive $dpiINDEX and only $dpiINDEX can vote on $DPI proposals and also any platform level INDEX. This somewhat reduces noise in governance like if we need to vote on DeFi meta-governance votes, somewhat that isn’t staked to $DPI (and therefore probably isn’t invested/knowledgeable in DeFi) can’t vote on what we do.

This is exactly what I meant by dpiINDEX

I am intrigued by the ideas mentioned in this topic from everyone here. However, I think it would be beneficial if we create two versions of DPI: conservativeDPI (like the DPI of today) and another agressiveDPI (the productive one being discussed). My reasoning behind this idea are two-folds:

  • Alpha-Investors (conservatives) who are prudent about risk and are comfortable about relatively low performance with low volatility would be more comfortable with idle basket of defi tokens. They are the ones who want to minimize the risk and are okay with higher opportunity cost. Because sometimes, you only want some exposure to the front-line of financial revolution, not being in the trenches with the lovely chads and degensquad. :laughing: For this type of investors, a product like DPI (of today) is suitable. Perhaps, we can focus with more decentralization and trust minimization for this conservativeDPI.
  • Beta-Investors (aggressives) who are comfortable with the inherent risks of smart contracts, open source protocols and Ethereum in general, want to maximize their exposure and minimize their opportunity cost. A product like agressiveDPI that seeks to maximize the possible gains of the underlying assets would be suitable for the crypto-natives. For this product, we can always try to incorporate more innovations from the community.

I believe having two types of DPI would be beneficial for everyone and will greatly increase potential users of DPI and consequently, Index community. I understand there will be some problem with liquidity, assuming total AUM does not increase in the short time-frame, but as an Eth-optimist, I would argue that this won’t be the case.


Edit: alpha and beta here refers to the financial terms related to risk and volatility. Not referring to popular internet terms related to pack-leader or follower.