Add vault that accepts yveCRV token as underlying and uses the weekly profits from the yveCRV vault to increase its allocation of yveCRV.
Background
The yveCRV vault accepts CRV and locks them indefinitely into the Curve DAO in return for weekly rewards.
Unlike most other vaults, the yveCRV vault doesn’t compound its earnings by re-investing (which makes sense as otherwise somebody who deposits would never see any money back as it would always be locked).
Motivation
Currently, if someone wants to re-invest the proceeds from the yveCRV vault, they must claim the weekly rewards and invest them again into the vault. These re-investments can be aggregated to reduce tx costs and they can be automated.
Specification
The yyveCRV vault accepts yveCRV deposits. Users can withdraw yveCRV from this vault at any time.
Depending on what implementation is most cost efficient, we check when new Curve rewards have been distributed on deposit/withdrawal of the vault (directly interacting with Curve’s reward contract) or we use a keeper cron job.
When weekly rewards are distributed, we claim and sell the rewards and either:
Buy CRV in the open market and deposit into yveCRV vault
Buy yveCRV tokens in the open market
Depending on the price of CRV and yveCRV (we’ll choose the option which provides us is with the maximum amount of yveCRV).
An auto-compounding yveCRV vault is something that’s under active discussion. Here are some ideas on the benefits and downsides from @lehnberg , @andy8052 , and myself. Would love to hear your feedback on this:
Benefits
Vault would allow for compounding growth of yveCRV (same as any vault)
Costs of compounding are socialized (same as any vault)
Would allow us to move Sushi LP rewards to a new ETH pair with the new vault token (will need a re-brand, but call it yvyveCRV for now). This would allow users to reap rewards both by LP’ing and also from their shares of the vault holding (as opposed to current situation where user can only have one or the other).
Number of taxable events user incurs is reduced as user will not be claiming 3Crv from the vault on a weekly basis.
Downsides:
This whole arrangement makes a confusing process even more confusing.(we think this can be resolved with good branding and communication)
New vault token, in theory, won’t maintain same 1:1 peg to yveCRV expectation since it is interest-bearing. (But because vault token can be unwrapped according to pricePerShare, we will be able always know exactly how much it is redeemable for)
Users who are in the existing Sushi pool will have to migrate. (We can create a zap for this to alleviate some migration costs.)
It could maintain a 1:1 peg if you wanted it to (save marginal rounding errors) by using a rebasing process similar to Ampleforth: uFragments/UFragments.sol at master · ampleforth/uFragments · GitHub. Sushiswap LP’ing would then no longer “work”, but having a Balancer smart pool like Ampleforth does which automatically adjusts the weights on rebasing would. I doubt this is worth the effort though, when you can be precise using pricePerShare, as you suggest
Sure
Another benefit I see is that it will increase the liquidity of the yveCRV token.
A potential downside I see is that one could expect this vault to buy CRV or yveCRV shortly after CRV rewards are distributed. This might cause some traders to buy CRV/yveCRV right before the CRV rewards are distributed to then make a small profit as the vault buys the token and the price moves slightly up. This could be avoided by having some sort of jitter that would buy CRV/yveCRV at semi-random moments during the week, making sure that all rewards are actually used before the next Curve ex-dividend date.
