The 2% cash grab

The 2% Cash Grab

I believe that an index provider should try to build a reputation for being a dependable custodian of our users assets. They should feel safe knowing that we will not take risks, charge excessive fees nor make frequent changes. We care for a users interests as though they are are own. This includes consideration holders, Liquidity providers, arbitrators and other protocols within DeFi.

However, I want to do an experiment. :man_scientist:

@Richard made an excellent proposal about DPI as a productive asset. In it he identified three methods that DPI can be productive

  1. Generating yields within DPI
  2. Becoming woven into the fabric of DeFi as another money Lego. Every time another protocol creates a way for DPI to be used increased the productiveness of DPI. A MakerDAO for DPI makes DPI more productive, as does the availability of aDPI or cDPI vaults.
  3. Becoming a positive influence within other protocol governance. By voting in ways that the underlying holders approve of, we help them gain confidence that we have aligned interests. Conversely, if we vote in ways against our holders wishes, they will be more inclinded to withdraw and hold the underlying tokens themselves.

Unsurprisingly, in this post I want to talk about the 1st method.

treasure chest.PNG

Aim

The aim of the experiment is to see if we can generate 2% yield pa on the DPI index. I want to run the experiment over one month, so the yield should target 0.16% [1.02^(1/12)]. i.e. $13 M AUV should produce $20,800 within one month.

Once we have demonstrated that we can generate the target 2% per year we can discuss how we can make this work for us.

I’m not a solidity programmer, so my proposal is pretty old school (circa 2019…).

Experiment parameters

  • 1 month period (~Monday 2nd Nov 2020 to Monday 30th November 2020)
  • On day one 45% of each and every undervaluing token in the DPI wallet (“DPI treasury”) is transferred to a multisig wallet (“DPI farm”)
  • The underlying tokens are then deployed in a range of income generating methods with the following restrictions:
    • Only deployed to protocols within DPI
    • No potential for slashing, divergence losses or liquidation
    • No withdraw fees
    • No AUV based fees (profit sharing fees are ok)
    • No withdraw time locks
  • At the end of the period, the yielding strategies are unwound. The same number of tokens deposited will be returned to DPI treasury to make it whole. Any additional tokens collected will be transferred to INDEXcoop treasury.

Outline procedure

  1. Formal IIP which passes
  2. Communication of strategy with wider community (holders, protocols etc)
  3. Transfer of 45% of DPI Treasury tokens to DPI farm wallet
  4. Deploy individual tokens to yielding opportunities.
  5. Monitor and manage the DPI farm. The DPI farm should be maintained within a 40% to 50% operating window compared to total DPI AUV. This will be done by addition of funds from DPI treasury and transfer to the yielding strategies, or partial unwinding and return to the DPI treasury. During any periods of DeFi volatility / network congestion, the multi sig holders have the freedom to unwind any and all positions to the underlying tokens.
    Note: All transfers between DPI treasury and DPI farm must be in perfect proportions compared to the most recent re balance.
  6. On or before the 30 November, all DPI farm positions will be unwound fully and the farm tokens (excluding yield) returned to DPI treasury
  7. All remaining assets in DPI farm would then be transferred to INDEX treasury.
  8. INDEXcoop will review the experiment and decide the next steps.

Success criteria

  1. No loss of any underlying tokens
  2. No liquidity shock in the DPI treasury
  3. Captured yield is > 0.016% of average DPI for the month.
  4. DPI farm does not significantly deviate from the 40% to 50% of AUV range for more than 24 hours in a single instance.
  5. No damage to INDEXcoop’s reputation as a custodian and partner in the community.

Notes on experiment design

  1. The primary aim is pretty straightforward – to get some income.
  2. Conducting the experiment will help our holders understand that we are seeking to capture internally availability yield.
  3. Conducting the experiment will also demonstrate to other protocols that INDEXcoop are willing to risk underling assets for yield. This will impact decisions made by others on whether DPI is listed as collateral, and the collateral parameters used.
  4. Communication / promotion of the experiment will demonstrate the INDEXcoop is working in an open manner to help us build a reputation for being trustful.
  5. I’ve deliberately made the entire process off chain. I believe that with suitable parameters, the strategy can be implemented without significant coding.
  6. By relying on the mutisig, we can avoid the time taken to plan, deploy and test code.
  7. The start and end dates were selected to be within a single rebalance period (1st business day of the month) This means that the rebalance can be done on a single vault (PDI treasury) which contains all the AUV at that time.
  8. The intention is for the experiment to avoid the end of the INDEX liquidity mining programme around the 5th December. I think the end of the liquidity mining programme is likely to result in significant redemption of DPI for the underlying tokens to access other yield generation strategies. By being 100% native token within the DPI treasury at this point, we enable a smooth operation of the market and out smart contracts. Note at any time during the liquidity farming INDEX, a better farm may appear which could have similar effect on DPI AUV.
  9. I would also prefer to avoid runing the experiment over the holiday period to reduce demands on the multi sig holders (although it does clash with Thanksgiving)
  10. A cap of 50% in the DPI farm was selected to help others understand the experiment, and the impact on their holdings / collateral parameters “About 50% is locked away”. I also believe that 50% cap displays that we are taking a cautious approach.
  11. Obviously higher proportions could be deployed to the farm to increase the AUV yield. However, I do not think we have a sufficient understanding of AUV behaviour to go higher at this time.
  12. By restricting yield generation to protocols within DPI, we will use protocols that our holders already selected as suitable for investment. In addition we help build our place in the Defi community.
  13. For each token I would select a single strategy based on track history and leave it in place for the full month. Chasing yield between aYFI and yYFI is not intended to be part of the experiment to reduce workload on the multisig during the experiment.
  14. Diversification between yielding protocols should be considered. Say no more than 25% of total DPI AUV / 50% of the farm within a single protocol (COMP, AAVE, YFI…).
  15. If no suitable yielding method is available, the native token will be hold in DPI farm.
  16. Transfers between DPI treasury and DPI farm must be done using all 11 tokens in a perfect ratio based on the most recent DPI rebalance. I understand that the DPI issue and redemption smart contract looks at the ratios within DPI treasury, so withdrawing (or adding) any of the tokens individually will change that ratio and push the DPI vault out of alignment with the DPI index / market cap weights.
  17. Underlying protocol governance using the DPI tokens is considered within scope of this experiment. i.e. they may or may not be done under instruction by INDEXcoop
  18. All gas costs will be taken from the yield generated before calculation of the AUV yield.
  19. The yield will be distorted compared to DPI balances (i.e. we my gain lots of YFI, but zero REP). To avoid complexity, rebalancing of the income is not anticipated until after the harvest and making DPI treasury whole.
  20. INDEXcoop will need to decide whether the generated yield should be converted to other assets within the INDEX treasury (ETH, DAI, DPI).

Costs

Other than the opportunity cost of time and effort on the experiment. I don’t see many significant costs. There is minimal coding required and a few transactions to pay gas on. There will be a cost for the multi sigs as they will need to manage the DPI farm and DPI treasury to respond to market and AUV changes.

Risks

  • I think total loss of the underlying tokens is unlikely given the use of battle tested protocols (COMP, YFI and AAVE).
  • There may be a liquidity shock within a single token (e.g. cUNI can not be with drawn because of high borrowing demand). This would make it impossible for us to transfer DPI farm to DPI treasury.
  • There is the potential for liquidity shock on DPI vault if there is a massive redemption of DPI. This could be caused by changes in the relative desirability of the DPI ETH liquidity mining. Another potential cause would be significant problems within a single underlying token.
  • There is also an opportunity cost as our governance, technical, and marketing efforts are directed to the experiment and not other activities that have larger long term benefits.

Timing

While I have suggested November, I actually see two options:

  1. November has the potential to capture the larger total value as I anticipate enjoying ~$13 M AUV though all of November. However, it also means that if we get anything wrong (liquidity shock), then we make a larger loss compared to the DPI index which we may feel bound to compensate from INDEX treasury. Running the experiment during liquidity mining means that changing market conditions (LM incentives) make the total AUV harder to predict.
  2. January, is likely to have less AUV, and so less total income from the experiment. However, we would be deploying a smaller farm and we should have a better understanding of the change in AUV over time.

Personally, I think early November feels too quick to discuss, propose, communicate, and implement. However, January 2021 is eleven weeks away, and a week feels like a long time in crypto. Possibly we reduce to two weeks in November.

I am looking forward to your thoughts.

Regards

OA

Should we run an experiment based on this outline to try and capture some yield from the DPI treasury?
  • Yes
  • No

0 voters

If we decide to experiment, when should we do it?
  • 2nd November for 4 weeks
  • 16th November for 2 weeks
  • January 2021
  • I still think it’s a bad idea

0 voters

4 Likes

Great stuff as always OA. Do we have any input yet from the technical guys on how easy this would be to implement? As a (mechanical) engineer the idea of kicking this out within two weeks seems ambitious but this is DeFi I guess!

It would be great to see some data that shows what size buffer is appropriate to avoid withdrawal/liquidity issues, and also what a realistic timeline for implementing it would be. Jan 2021 certainly seems safer in terms of both time to deploy and amount of AUV affected, but understand the trade off might be not so many people are exposed to the greater reward of yielding assets.

I would hope as a user that it’s not possible to send the tokens out of the vault in the way you describe and the manager can only use the modules allowed in the system but lets se what Set team says.

There’s also the legal side of things to worry about since this would be humans and not smart contracts doing everything but whatever.

Since a lot of DPI seems to be farms like Alpha finance I’d say ending it before INDEX distributions is over is a good idea.

As far as yields go, I looked through the platforms and it seems these are the best options:

token platform APY
YFI yGov 10%
UNI Compound 3%
COMP Compound 1.5%
MKR Aave 0.3%
SNX Aave 0.4%
REN Aave 0.11%

I don’t think there are any other yields that fall under your criteria and are claimable within the 1 month time period. It’s not great but not bad either. If my math is correct, we would make about $8,000 off YFI alone ( $15M(AUV atm) * 12%(index weight) * 50%(half to farming) * 0.83%(1 month yield) ). This yield actually might be a bit higher since I’m basing it off the yYFI vault yield and that may or may not be inclusive of fees.

If it’s possible to send the tokens to a multisig from the vault I’m down. I think November is fine because this is all pretty standard, battle tested protocols and shouldn’t really offend anyone by doing yield farming, if anything its good marketing. I would probably only put 25% of the tokens into Aave just as a precaution.

1 Like

Cheers,

10 days is silly fast, but I don’t think it needs any smart contracts apart form a new multisig. Obviously there needs to be a few bits of admin / paper work to do first. However, we would certainly need a sniff test feom Set Labs before we go further (like a sench check, but focusing on the overall smell :nose: )

The AUM is pretty good at the moment, but I suspect most miners are mercenaries chasing the best yield

Delaying to Jan only has three impacts: likely less AUV, so less added to the treasury, the DeFi market will have changed (I’ve forgotten what was hot 11 weeks ago…), and we may have been incorporated into other protocols (who may have assumed DPI will only hold the native tokens).

Thanks Kiba,
I think the multisig can withdraw from the DPI treasury. That’s how they claim the streaming fee. See Felix’s reply and links to dev docs to my questions . But I’m no expert on code.

Legal risk for the multisig isn’t something I had considered.

I restricted the yield opportunities so a set that few would have objection to. I’m sure that there are better yields out there. I’m happy to miss the 2% target if the reason was that we were cautious in this experiment.

Unsurprisingly, I’ve been thinking about how we can use the income. :owl:

We currently have 190,000 DPI tokens issued, so 0.16% collected in 4 weeks would be about 300 DPI. I would convert the captured value into DPI, then announce that from a set date, we would distribute the 300 DPI at an annualised rate of 2% pa. Then it is exhausted at a period that is entirely dependent on the number of tokens issued (independent of $DPI market price). This should be a simple message that is easy to communicate (300 DPI distributed at 2% PA until it’s all spent, effectively 1% reward):

  • 190,000 DPI issued ~ 4 weeks
  • 95,000 DPI issued ~ 8 weeks
  • 47,500 DPI issued ~ 16 weeks
  • 15,000 DPI issued ~ 12 months

A simple marketing hook to combine with the inherent benefits of diversification within DPI.

1 Like

I like the idea. This is a great opportunity for the Index Coop to become sustainable, which is something important in my eyes as you may have noticed.

We also have to take care and be fully transparent regarding the use of the funds. This must be tracked and shared clearly with DPI holders.

Also, this could be a new kind of ‘rebalancing’, happenning everyday in an automated fashion, comparing the amount of productive DPI vs non-productive DPI, and rebalancing depending on the mints/redeem of the day.

1 Like

For the experiment I don’t think there is a need to rebalance as its a short period. It would also cope with YFI staking paying in yUSD. Basically after 4 weeks we transfer everything back that was put in, and see whats left in the bottom of the wallet after we have paid gas.

If we decide to implement something similar long term, then it would need some time to design it so it preserves the underlying token rations with the DPI treasury. Then there is the challenge of running both over a month rebalance. Monthly unwinding and then redeposition may cause problems for the compound / AAVE vaults or any future techniques that have a lock in.

I think I’ve made the experiment as simple as I can, we could certainly go more aggressive with % in the farm,. or protocols selected, but I would prefer a secure trial that misses the 2% target than too much risk.

Following up on the productive asset conversation, this is a really cool idea, like the spirit of experimentation, and appreciate the clear success / procedural guidelines.

In terms of technical details, wanted to clear up some potential misconceptions:

  • The Index multisig doesn’t have the ability to arbitrarily make transactions, to move DPI constituents, or to stake them. Instead, it has the ability to add “modules” or pieces of functionality enabled by the Set Protocol. Some of these modules can include staking, wrapping, voting, etc. Some of these modules are available already like Wrapping (can wrap assets into cTokens or aTokens) and many other simple functionality like Staking can be ready easily. Thus, there would need to be some dev work required to enable this functionality (but not too much).

That said, I think the restrictions of limiting certain behaviors is certainly a much better middle-ground. Of the top of my head, there are a few things we need to keep in mind:

  • Percentage of tokens put to work may present risk: With putting assets to work, there is the risk of inability to redeem. Though that really has to do with a few factors like 1) aggregation of DPI in lending protocols, 2) large whales that may want to redeem at once, etc. If sufficiently diversified, the 40/50% amount may not be very problematic.
  • Data on 3rd party integrators: I think we do want to see and get feedback from folks like Compound, Aave, and Maker what they think about the experiment before they run it. It may allow us to get feedback earlier and derisk things like “damage reputation as custodian and partner”, etc.

In general, I do think the demonstrating ability / capabilities to generate yield are important and may reveal important facts about the desirability of the DPI. At the same time, I wonder if we can get more qualitative evidence / feedback and derisk by having conversations w/ users / protocols to get the same answers w/o the full on experiment

4 Likes

YFI staking is the least risky + highest reward yield + retain voting power and doesn’t require analysis like lending protocols do. Besides minor smart contract risk from staking (which safely held like $100M in YFI at one point) there is no potential loss of funds since they aren’t collateral or available to withdraw by others. There’s no possibility of double dipping in lending protocols and it’s the safest possible yield in DeFi as far as I’m aware so I think it will be fine with integrating protocols.

There is the question of whether to use yYFI vault vs staking directly to yGov. I assume building the module for yYFI gives us access to any yX vault in the future with no additional development. Staking to yGov has higher yield because no vault fees + less smart contract risk than vaults + no strategies potentially losing funds so it’s the “boring” route and yYFI is just doing governance staking anyway at the moment so staking directly would be my recommendation if we move forward with this.

2 Likes

One reason I’m against rushing into this decision is that we’re very well positioned to become one of the most trusted DeFi assets. The faster we move and the more layers you add between the underlying base asset by staking and lending out assets, the higher likelihood of eroding this trust, brand and narrative of being a “boring” asset. Harvest had over $1B TVL and just got exploited due to them not completely understanding how Curve works, so can’t use capital as a proxy for how safe smart contracts are. This would shift DPI from a passively managed product to a higher risk actively managed one.

Had some additional thoughts I’ll put in another post that can potentially achieve this goal of generating yield and additional fees to the coop, without pivoting the DPI’s brand/narrative or cannibalizing DPI through launching another product

4 Likes

Security of users assets and trust have got to be our overriding goals.

I think there are three benefits from doing it quickly, in a controlled manner.

  1. We gain confidence that we can secure some of the potential earning for INDEX holders benefit.
  2. we show DPI holders, that we are looking at ways to reduce AUV costs.
  3. we show the lending protocols who we want to add DPI as collateral that we intend of farming part of the AUV.

I think it’s better to talk to to the lending protocols with farming DPI underway, then they can see what we are doing and how careful it it. I think being added as collateral as 100% passive, then changing could be a surprise to some protocols (which we would try to avoid by communication during the collateral on boarding process).

Any farming will add risk to the AUV, so we have to be careful. I was trying to be very conservative in the criteria I suggested.

My worry is that if we do nothing before the end of liquidity mining we will loose lots of AUV, and some momentum that we won’t regain until the new year.

I like the idea of running our own arbitration bot and adding a issue / redemption fee. It would be interesting to see how much that would generate.

Looking at the dune analytics it looks like ~ 36 PDI redeamed, ~$2.7 M, 0.5% would be $13,500 since launch, that is a pretty good income stream. I don’t know if it’s easy to capture.

As mentioned yesterday, we definitely need to put in the work these underlying tokens. But, I would require end users to deposit their DPI in a dedicated yield farming Smart contract first where the DPI is locked while being used. We want the DPI itself to be usable as collateral and we want to serve different kinds of customers (low risk and high risk ones). We could issue a yDPI to users when they lock their DPI in the SC, so that it’s still tradable and equals to creating a new productive DPI, but without creating a second index. We could then implement a performance fee on the yDPI when sold back for DPI :ok_hand:

2 Likes

I think that we can access the underlying assets for farming without changing anything for the external users (holders, arb bots, creation, redemption contracts).

If we use the governance contract to remove that correct proportion of ALL the tokens (say 50% of YIF, MKR, AAVE…). Then redemption and issuance of the underlying tokens with the main account will work perfectly.

We then have 50% of the total AUV in a separate wallet, with the underlying tokens in perfect market cap balance. Then we can farm those tokens that have a suitable farm.

So long as we have sufficient liquidity in the DPI treasury (i.e. the address that everyone interacts with) then no external interactions need to be changed.

At the monthly rebalance, we would need to rebalance both wallets (which is why, I would run the short cash grab experiment between 2 rebalance events).

It does change the risk profile for holders as we could face a liquidity crunch if over 50% of DPI was redeemed quickly. But I don’t see a long term risk of the underlying assets (i.e. I think YFI, AVVE and COMP are safe deposit).

1 Like

I think both cases end up putting DPI underlying tokens to work, which is definitely great :slight_smile:

The difference is that either we give customers the choice to do it (via a yield farm deposit) or we force them to do it and we end up having to manage a minimum capital available to avoid a liquidity crisis (it’s a « banking » model). I’m not sure to understand why the second option would be more suitable than the first one. The first one empowers more users imho.

1 Like

With increasing our exposure to yield farming, it becomes imperative that we insure ourselves from potential losses. What would you say to shield mining using Nexus Mutual? We provide the nexus mutual assessors a certain amount of $index token( per specified time period) in exchange for Nexus supplying cover to our underlying assets.

1 Like

I agree with that.
Maybe I don’t have a big enough picture, but I feel like the opt-in framework is the only safe one.

image

From the DPI Uniswap LP token information ($876.01 | Uniswap DPI/ETH LP (UNI-V2) Token Tracker | Etherscan) it looks like the daily volume was above 80k LP tokens per day for three days in a row. The total supply of DPI UNI LP tokens is around 70k. While I am not sure how to interpret it, it looks like A LOT has been going on at the start of the Index Coop launch. I don’t see why such a spike in activity could not happen again, hence locking even 10% of all of the $DPI looks like a risky move to me.

Here are the txs from and to the staking contract around the same dates : $876.01 | Uniswap DPI/ETH LP (UNI-V2) Token Tracker | Etherscan

There are probably 500 holders or so of the $DPI index. As we saw previously in DeFi, capital can move extremely quickly when controlled by such a low amount of holders.

A viable solution could be the following :

  • A new “locked staking” contract where users can put their DPI to accrue both in-kind interests and $INDEX rewards.
  • A new “locked staking” contract where users can put their UNI LP DPI (to keep the liquidity incentive going) to accrue both in-kind interests and $INDEX rewards.
  • We keep the existing UNI LP DPI staking contract with $INDEX rewards.

This way, the $DPI are set as productive assets on an opt-in basis, with a double incentive to take the risk (interests accrual + $INDEX rewards). On the other hand there would eventually be a delay between a withdrawal request and an effective withdrawal, or more simply a cap/limit on the staking contract.
Keeping the original $INDEX staking contract in parallel means the original promise of it is still fulfilled with no extra risk for those you “bought” that narrative.
Adding an extra LP UNI “locked” staking contract with interests accrual and $INDEX rewards allows to boost returns for those who want to continue to be an LP but still want to accrue interests. It also avoids the situation where LPs are suddently descentivized to provide liquidity, should interests accrual in the “locked staking” contract become greater than LP $INDEX rewards.

2 Likes

You make some excellent points here and I think influenced @setoshi 's post in this thread Intrinsic DPI Productivity w/ $INDEX as Risk Backstop

I think most of the this discussion has continued in the thread above.

I’m (currently) leaning towards:
INDEX staking for risk backstop / rewards (as INDEX and $DPI / other ?)
$DPI and DPI-ETH LP staking for rewards (As INDEX and $DPI)

INDEX to come from treasury as a method to incentivise staking and distribute INDEX.
DPI to come from the farming.

90 day lock in for both types of staking (mainly because I think it would be simpler to implement)

1 Like