Some thoughts on yVault Product Strategy
I’ve spent a few weeks in the Yearn ecosystem and have been consistently impressed with the quality of community, as well as the incredible pace of progress (even if it’s not always visible from the surface). It’s certainly a community I’m proud to be part of.
This post is an attempt to collate & structure some thoughts I’ve had while contributing. I was hoping to post a refined set of thoughts, but this community moves so fast I’m posting these very half-baked ramblings in the hope of contributing to the discussion. Forgive me for any misunderstandings or bad takes.
Product Strategy
I came to think about Product Strategy for Yearn largely as a result of participating in the Naming Conventions conversation.
Yearn is still young and we certainly have opportunity to redefine naming conventions, but I think it’s important that we have a thoughtfully determined convention for naming that will serve future product releases well, otherwise we risk introducing user fatigue by changing Naming Conventions again in the future.
Therefore Product Strategy is a key input to the process that defines Naming Conventions.
yVaults
As a user of V1 yVaults, I would frame (my own) user intent as:
XYZ yVault:
I want to retain exposure to XYZ asset, but I want to put my capital to work and generate yield to increase my holdings of XYZ.
I don’t mind if the capital is put to work directly, or whether it is safely leveraged and debt is used to generate yield, so long as my principal is not at (significant) risk.
I do not want to move my capital. This is a set-and-forget deployment of capital and I expect that Governance will allocate my capital to maximise yield while managing risk.
The want token
In terms of the intent above - one issue with V1 yVaults is that some of them target (as the “want” token) active positions in DeFi (e.g. yyCRV - presently aka yUSD - “wants” Curve yPool LP shares). This isn’t ideal because very rarely will a user want to go long on a specific position (even though automation/position management is desirable), they likely want to go long on the token that the position is maintaining exposure to. This approach will likely force withdrawals in the long term as a given yVault cannot allocate capital to any other position - it’s stuck farming the position defined by the LP “want” token.
Therefore the “want” token defined for the yVault greatly constraints its capabilities. Vanilla-yVaults, those “wanting” unpositioned assets like ETH or LINK or WBTC are most capable in how they are able to deploy capital to generate yield.
Vanilla yVaults:
Generally a retail user will want to go long on a token, and should therefore expect that the yVault will allocate that capital to positions that make most sense. If I put money into a ETH yVault, I’d expect the yVault to determine which positions (presently) make sense, allocate capital there and farm rewards, and then as incentives and market forces change, reallocate my capital to better yielding positions.
In terms of the user intent described above (“the retail user”), yVaults targeted at typical retail users should “want” vanilla tokens. The yVault should then manage that capital across a variety of active positions (as implemented by active Strategies on the yVault).
Pros: Set and forget, can completely change underlying positions to track best yield over time
Cons: You are stuck with the position/strategy allocations that the Vault makes
Position yVaults / yield legos
There is type of another user - active capital allocators and other protocols (like Rari Cap) - that are looking for position/farming automation, but want to do position allocations themselves. These users may be interested in yVaults that “want” a position token (e.g. uni dai-eth LP) to automate farming it. I think of this use case as “yield legos”. It’s worth thinking about whether we should differentiate products intended for different market segments (passive vs active allocators).
Pros: Automate farming a particular DeFi position, control exactly which positions you take
Cons: You have to do allocation work yourself, moving capital as the yield profiles of positions change
Open Questions
This leads me to think that Yearn product composition is worth thinking through. Some open questions:
- Is the complexity tradeoff of decoupling Strategies from a single yVault (and making them available as yVault-independent yield legos) worth it?
- If we support the idea of “yield legos”, then should vanilla-yVaults be built on top of these? i.e. should they allocate their capital to yield legos?
- Should yVaults simply exist as automation wrappers for both vanilla tokens & LP tokens, and users just pick vanilla-token-yVaults if they want a “set-and-forget” product or a LP-token-yVault if they want to actively manage capital allocation across positions? Do we care about the inefficiencies of this approach (segregated holdings in the same position without knowledge of each other)?
Meta-Vaults
(Disclaimer: I feel poorly-educated on the intention/design vision for Meta-Vaults, so rampant speculation ensues)
… or, maybe the teased Meta-Vaults are intended to be the retail product. So yVaults automate the management of capital for specific positions, and then Meta-Vaults provide a “retail entrypoint” for the set-and-forget deployment of capital.
Example:
yUSD Meta-Vault deploys capital into multiple stablecoin-LP Vaults (e.g. curve.fi/y LP, curve.fi/busd LP, etc), which in turn leverage Strategies to farm these LP positions (seems unlikely that there will be more than 1 Strategy for a given LP position) and bubble yield all the way back up the Meta-Vault.
Personally, I like the idea of Meta-Vaults offering “meta” yield-bearing exposure to an asset across many tokenised representations (via vanilla yVaults).
For example, Meta-Vault yUSD farms stablecoin yield, across a number of stablecoins which are all tokenised representations of USD. Critically, there is no USD token to “want”, that’s what makes it meta. So yUSD will include exposure to DAI, USDT, USDC, etc (via yVaults, e.g. yvDAI) to maximise USD-denominated returns. If yield is distributed as income (e.g. aToken style rather than cToken style), this has the side-benefit of creating a meta yield-bearing stablecoin for the ecosystem.
Another example - there is no native BTC token on Ethereum, only a variety of tokenised representations. There can’t be a BTC yVault, but there can be a yBTC Meta-Vault which delegates capital to tokenised-BTC vanilla yVaults like yvWBTC, yvrenBTC, yvtBTC, etc.
Fees
Active discussion: Proposal: Revamping Fees
Another benefit of focusing on yVaults for vanilla-tokens is that fee revenues are maximised for the protocol! LP-position tokens may wrap underlying yield (e.g. yCRV – not yyCRV – wraps lending yield from iearn and swap yield from Curve) and yVault fees therefore do not benefit from that yield since fees are only charged on harvests (active strategy operations).
For vanilla-token-yVaults, fees would be generated on all composed yield that the yVault achieves.
Important variables
As yVaults mature and move beyond simple-farming Strategies, additional variables emerge as important to consider (within naming conventions and our broader product vision & framework).
These are some of the things that should be assigned to each new yVault and included in its data sheet (and probably contract data schema):
Risk Level
Qualitative risk measure (say out of 5). Governance should then allocate Strategies accordingly across yVaults.
- How does Insurance fit into this?
Strategy Types
This refers to the type of Strategies that the yVault will engage in. Likely based on Risk Level.
Examples: No-IL Farming (e.g. CRV-farm-and-dump), IL Farming (e.g. UNI-farm-and-dump) vs Directional (leveraged exposure) vs …
- What other Strategy Types are on our collective radar?
Yield Type
Distributing (yield is distributed as income) vs Accumulating (yield is wrapped and treated as capital gains).
- Do we want both options for yVaults/MV?
- Can this be implemented as a dual-class yVault-share structure?
Product Version
Not contract version, but product version. As we migrate to new yVault designs, including a version within the product data may make the Yearn product ecosystem less confusing/aid in the migration of capital to newer yVault designs.
Hopefully these thoughts are useful. Looking forward to any discussion they generate.