What is Intrinsic Productivity, and why is it inevitable?

What is Intrinsic productivity, and why is it inevitable?

I’ve blogged about some of this in the past (RIP overanalyser.medium.com – soon to be migrated to my substack: https://overanalyser.substack.com/)

What are productive assets?

Productive assets are ones that generate profits and cash flow. Farmland, rental properties, and dividend-paying company shares are all productive assets. Non-productive assets don’t produce income but may have other properties that are valuable. Gold is the classic non -productive asset that manages to retain its value.

However, nonproductive assets can be used to generate income. Gold can be used as collateral to raise a loan to invest elsewhere. So, I like to consider the intrinsic and extrinsic properties of an asset.

Extrinsic productivity

For a fund token like $DPI, there are may ways it could have extrinsic productivity (which can include income generation, but can be other uses that produce economic value for the user):

  • Placing it on a lending platform to earn income (Cream, AAVE, Compound)
  • Using it as collateral to earn income, and allow borrowing (Cream, AAVE, Compound)
  • Using it as collateral to generate DAI from a MakerDAO vault.
  • Borrowing and selling to short DeFi
  • Buying calls and puts on Opyn
  • Provision of liquidity for DEX fees (Uniswap, Sushiswap, Linkswap)
  • Staking Liquidity pool tokens to mine other tokens (INDEX, Sushi, BOA, YFL)
  • Staking the fund token for income.
  • Arbitrage can capture any movement off the NAV by minting or redeeming $DPI.

One key feature of all these is that they are generally, mutually exclusive. You can only do one at a time. Although if you get a token in return, there may be other options built on top of the first. (e.g. staking a LP token). However, this takes time and resources for Devs to build.

The INDEXcoop has no veto over what forms of extrinsic productivity are built upon our tokens, nor which forms our users decide to use. However, we can encourage the formation of opportunities for holders by offering incentives (Liquidity mining), building out code / offering technical support (AAVE v2), making applications to other protocols ( AAVE, Compound, Cream, MakerDAO).

In addition, the INDEXcoop has no way to capture income from extrinsic productivity.

Intrinsic productivity

For an index fund, I use intrinsic productivity to refer to productivity that is available within / underlying the fund token. This is separate to extrinsic productivity and allows a double dip on income generation.

As DeFi / Crypto natives it seems obvious that holding many tokens for pure price exposure is leaving some income behind, we know we can lend / stake / use them as collateral. Therefore it seems that a fund made of passive tokens is a missed opportunity.


There are two important points about intrinsic productivity:

  1. For $DPI, INDEXcoop, as the issuers, are the only organisation capable of building ways to capture intrinsic productivity while maintaining the integrity of the DPI.

  2. Intrinsic productivity is completely independent of extrinsic productivity – We can do what we want, and it it has no direct impact on how $DPI user capture extrinsic productivity.

I think there are two main ways that an index builder can capture intrinsic yield for ourselves / our users; build it from income generating tokens, or farming part of the treasury.

Using income generating tokens

Building a fund from income generating tokens is certainly possible (PIEdao have done it with YPIE , the issue and redemption contracts just need to use the corresponding tokens.

So, why don’t we build all funds out of income generating tokens?

  1. Promises of future income is one of the criteria to be a security.
  2. Many of the income generating tokens are only available by a single contract with minimal secondary market availability.
  3. This is particularly important when the income generating token has a time lock
  4. For third party income generation, the best deal changes over time (e.g. cUNI vs aUNI).
  5. Every change to the make up of the fund composition (aUNI to cUNI) requires modification to our issue and redemption code, arbitrage code, and price oracles.
  6. So more complexity adds work for others which means they may be less likely to use us.
  7. Some tokens you may want to include don’t have a readily available income generating token.

This approach can work with small funds and may be more attractive to DeFi natives but it reduces the size of the potential market ($YPIE is $300 k AUM compared to $38 M for $DPI).

As such I don’t think such an approach is our best route for $DPI as we focus on growing AUM [It may produce a sister product in the future as DefI grows)].

Farming the underlying tokens

The basic idea for this is that the DPI treasury contract holds all the deposited tokens in the correct weights. The issue and redemption contracts then issue / burn $DPI in return for / providing the underlying tokens.


We, as the developers of the contracts, can remove tokens (as is done to rebalance etc). However, If we change the number of a token, any issue and redemptions will reflect the current composition and so pull the pooled fund off the index composition weights published by DeFi pulse.

So, if we want to farm the underlying tokens, we need to deploy an addition pooled fund contract “$DPI farm”.

What are the risks of this approach?

There are two main system risks and few more social risks.

In current operation, the $DPI treasury has assets and liabilities that match exactly. If we implement the spilt pool system with farming we introduce the following:

  1. If we transfer a large proportion of the underlying token s (that we are responsible for holding for our users) to the farm wallet and there is a sudden increase in the number of $DPI compared to issuance (e.g. market uncertainty particularly with regard to deFi and / or our smart contract). Then there may be a point where there are insufficient tokens to satisfy a redemption contract. This is effectively a liquidity crunch for DPI.

2) The farming tokens may have a value less than the corresponding native token. For example, compound has an exploit and cUNI and COMP become worthless. COMP becoming worthless has no impact on DPI as we have a liability to repay COMP tokens to any redemption. However, we would be holding worthless cUNI as assets, while having a liability for UNI. So we have a shortfall assets compared to liabilities. It is an asset liability on $DPI.

Of the two, the first possibly has more impact as it then upsets the other DeFi protocols (liquidations, arbitrage, deviation to NAV) and may cause cascading failures for others.

The second would result in a financial loss to the coop as we would most likely need to make up the difference in assets and liabilities.

Personally, I think the second is likely to allow some time to react, in order to state that we would cover such losses (which could be ~20% of DPI). However, it’s likely that the second could cause a run of redemptions that then pushes us towards the liquidity crunch…

Social risks,

The other risks relate to how our users and other protocols see us. Any form of intrinsic productivity introduces risks. So very risk adverse groups my decide to hold the native token instead. Other protocols (lending platforms et, may see the implementation of intrinsic productivity as being undesirable, so they decide not to integrate with DPI and so our users loose a potential source of extrinsic productivity.

In addition we need to ensure that anyone looking at coop AUV sees the value of both the DPI treasury and the DPI farm.

How can we manage the risks?

Liquidity crunch:

To be 100% certain of never having a liquidity crunch is to incentivise DPI holders to lock up tokens for a set period, then we can farm the corresponding underlying tokens confident that the DPI treasury always has the liquidity required for 100% redemption of circulating DPI. This has been discussed in a few forum posts:

This is the safest method to manage the farm however, there are a number of downsides:

  • DPI holders have to lock their tokens for a set time.
  • DPI tokens have to spend gas to deposit, unlock and claim rewards.
  • DPI holders can not use any other forms of extrinsic productivity.
  • The coop needs to write, verify and deploy more contracts.
  • The coop will need to share the income generated with the DPI stakers.
  • Initially the intrinsic productivity may be loss making for a longer period.

The alternative is to take a risk based approach, and remove part of the tokens in the DPI treasury without locking the DPI. This avoids all the downsides above, but exposes us to the liquidity crunch.

In order to understand this risk we can look at DPI tokens and how long they have been static, long held tokens can be assumed to have some stickiness and so unlikely to be redeemed.

Tokens in liquidity pools, are a different matter, some will only be issued for as long as there is an ongoing liquidity mining programme. So, at the end of such programme, there is likely to be a net redemption of some of the tokens as the LP farm is unwound. However, as liquidity is removed, the income from swap fees will increase.

Overall, I believe that over time, we can gain an understanding of how sticky our product. Currently over 50% of DPI is not in a liquidity pool. As we build better analytical tools and observe for longer we should get a better idea of a safe number of DPI we can farm

Asset liability

I think the key to control the asset liability is to be careful how we select income generating uses. So we could apply a few criteria:

  • Established protocols with a good track record
  • Large market cap compared to the value we would investment
  • Native staking preferred over lending
  • No borrowing against the deposit.
  • No time locks

Practically, this may limit us to AAVE, Compound and governance staking while we wait for DeFi to mature.

Opportunities like xtokenmarket offer better yield, but we may decide to limit the proportion / value of the farmed tokens deposited.

What about INDEX staking as a back stop?

Index staking has been talked about for a number of angles. These include making INDEX useful, productive (and so higher value which increases the war chest), and providing a financial backstop to cover the initial losses if we face an asset liability.

Personally I’m in favour of this as I think it would achieve a couple of goals.

Social risks

The main ways to control the social risks is to be open about what we are doing so others can assess them.

In addition, providing a INDEX based backstop should help build confidence that we are being suitable cautious with the assets we are looking after.

What is the goal for intrinsic productivity?

The goal for intrinsic productivity is to build an additional income stream for the coop. The safest options will capture ~2% on the tokens farmed. In the future I would expect higher yields (e.g. YFI governance rewards increase, xSushi, use of xtokenmakret, borrowing against collateral to farm stable coins).

My goal would be to be able to entirely subsidise the streaming for (0.95% for $DPI) so holders are effectively getting a free ride. To do this I would want to be routinely capturing at least 3% of the total DPI treasury (and so a much higher income form the $DPI farm).

I don’t think paying income (a -ve fee) to DPI holders is a good idea as that could be considered a security and open up a few new legal questions for some institutional holders.

Rebalances are a huge challenge for the split pool strategy

There are two potential strategies:

  1. Unwind all the farms, return the deposited tokens to the DPI treasury before the rebalance, then redeploy the farm.

  2. Rebalance the treasury and Farm separately.

The first may be preferred initially as we have fewer tokens being farmed. However the second my be more efficient as we start to employ more complex farms / lock up tokens.

What are the other challenges?

The other challenge to initiating intrinsic productivity is developer time to write, verify and deploy the contracts.

In addition, if we use DPI staking, we need to publicise the programme to get people to deposit, and we need to schedule the dates with any ongoing liquidity mining.

Finally, there is the challenge of managing multiple activities at once, even with unlimited Dev time, the community would need to manage the implementation of intrinsic productivity while assessing new fund proposals, supporting new fund launches, growing AUV.

Why is intrinsic productivity inevitable?

There are a few answers:

  • There is income available that only the fund creator can capture.
  • Our DeFi customers will expect us to do it
  • It is technically possible to do it while managing the risks
  • If we don’t do it, someone else will, and they will have a larger income to capture AUM.

So, if it’s inevitable, when should we do it?

For me this is the $6,000,000 question.

It’s got be a balance between resources / risk and income:

  • A simplified approach for $DPI could start relatively quickly (say 2 months) and then snow ball as more farm contracts are added.
  • A strategy based on more contracts and DPI staking will take longer to deploy (4 months?) but have lower risks.
  • Delaying the start of work on intrinsic productivity allows devs to focus on other activities, and us to build more data on DPI stickiness.
  • Delaying until after CGCI launches may allow the intrinsic productivity to focus on CGCI which may have a better risk / reward / work profile.

So, these my thoughts on one of the key ways the coop will eventually capture income from our AUV, What do you think?


@setoshi @DarkForestCapital @verto0912 My long promised post on WHY Intrinsic productivity.

I think there are some more links (inc to additional blog posts to be migrated).
But I think I’ve captured the main points.

This is a great summary and agreed it is inevitable and more about when timing / resources make sense.

That said, I think we should keep pushing things forward so that engineering can pluck this off and implement it when ready.

I think we’re ready to start putting together a product specification for this, which details all the interactions, how it works, etc. It wouldn’t look too different from a whitepaper or so. We can discuss this in the next product meeting!

1 Like

Sounds good to me.

Get an agreed route and let the Devs work in it when they get a chance.

Great dive into this. It does seem inevitable and that the benefits can be chosen and ramped-up over time.

A question that came to mind was how would this impact the platform voting capabilities of INDEX? It seems a proportion would be lost, but also that some could be gained if holding tokens in, for example, Compound.

1 Like

Thanks @overanalyser, this is great stuff!

I think that everyone is probably in agreement that intrinsic productivity will happen in the index space sooner rather than later.

The more important questions are around the timing and the mechanics. I leave the mechanics to you as you’ve spent much time on this.

On timing, I think there’s nothing (other than dev resources) stopping us from setting up the farm. Farming using Treasury tokens is our prerogative and, technically, we don’t even need to backstop it with staked $INDEX. Once we trial this out and with better analytics, we can consider extending this to external $DPI holders via staking and lock-ins.

I don’t think it matters much whether we do it now or with ETH after CoinShares index launches. Yes, perhaps doing intrinsic productivity with ETH via ibETH or stETH will yield better results. But these protocols are less tested than Compound and Aave & stETH, for example, can deviate from 1:1 peg to ETH.

In my mind, timing largely depends on the availability of development resources. If we have capacity, then let’s start building the contracts. If there are other priorities, let’s push it back.

1 Like

Great nuance overanalyser. It seems like you foresee that adding contract risk to DPI might change holder distribution an potentially scare off risk averse investors. What if there was a staking contract to deposit DPI in to get a share of the rewards that the contract accrues as it that performs the actions you suggest? Staking is a well-known concept and it leaves an opening to those who wish to hold DPI without staking.

1 Like