# Proposal: Update Vault Fee Mechanics to Enable Composability Between Vaults ## Background Let's first outline the three mechanisms in which fees are applied to vaults. 1. **10% Performance Fee (Strategist)** - Collected at `report` time by the vault based on `vault.strategies[strategy].performanceFee`. Configurable for individual strategies. 2. **10% Performance Fee (Governance)** - Collected at `report` time by the vault based on `vault.performanceFee`. Configured globally for all strategies. 3. **2% Management Fee** - Collected at `report` time by the vault based on `vault.managementFee`. Configured globally for all strategies. ## Assumptions / Notes: - All references to vaults and strategies below are v2 design only. This assumes a complete migration off of v1 which have a different fee structure. - While this proposal covers Curve vault architecture specifically, the core concepts are applicable to non-Curve strategy design as well. - While the illustrations in this proposal show the flow of capital behind the yvDAI, the core concepts are applicable to any vault with a `want` token that serves as a Curve pool base asset. ## Problem > **Current fee mechanics break composability.** > As it stands today, v2 fees are applied to each strategy on each vault. This greatly impacts a strategist's ability to chain vaults together in a composable way to access additional yield opportunties without also incurring duplicate fees on users. The graphic below illustrates an example of how a set of strategies flowing across multiple vaults suffers from our current fee mechanics. Fees are taken at every hop - turning a potential strategy profit of, say, $10,000 into a profit of $4,745.52 in some cases by the time it arrives back in the yvDAI vault. ![](https://i.imgur.com/c9EdVRy.png) ## Proposed Changes 1. **Vault code modifications:** - Today, in the vault contract, a single `vault.performanceFee` variable controls all performance fees which go to governance. This shall be updated to allow governance performance fees to be applied on a per-strategy basis, e.g. `vault.performanceFee[strategy]`. Doing so would allow us to set fees for non-yield-earning strategies to zero, while also leaving fees intact for yield-earning strategies. - Today, in the vault contract, a single `vault.managementFee` variable controls all management fees which go to governance. This must be updated to allow a management fee on a per-strategy basis, e.g. `vault.managementFee[strategy]`. Doing so would allow us to set fees for non-yield-earning strategies to zero while also leaving fees intact for yield-earning strategies. 2. **Optimized fee placement:** - Fees (both mgmt and perf) should only ever be enabled on the yield-earning strategies (e.g. Curve strategies which touch a Curve gauge). Alternatively, if fees were instead applied to the user-facing vault in the example above and not the yield-earning-vault, then this would result in users being able to enter directly into vaults nearer to the gauge and completely bypass fees. - Fees (both mgmt and perf) should be set to zero on all non-yield-earning stratigies (e.g. other upstream strategies which do not touch a Curve gauge.) If implemented, these changes will result in the following fee outcomes as applied to the previous example: ![](https://i.imgur.com/UH1HznZ.png) ## Benefits - In this example, all fees are turned off for non-yield-earning strategies. yvDAI depositers will only realize fees a single time. Fees will reliably adhere to the target amount (2%/20%) regardless of which route funds take. $10,000 profit always becomes $7,800 after fees, no less. - Using this design allows users to deposit into any vault at any point in the pipeline and will only ever realize fees on their profits a single time, never more. - Finally, this change will allow us to adjust fees specifically on targeted, and will not impact other strategies connected to the vault (e.g. the non-Curve Yield Farm in the diagram below). ![](https://i.imgur.com/3QZ5h12.png) ## Potential Downsides 1. Single sided deposits/withdraws become necessary at each hop. Increasing risk of side-effects and even hacks ([see here](https://github.com/iearn-finance/yearn-security/blob/master/disclosures/2021-02-04.md)). - v2 vault design offers far better protection against risks of single sided desposits/withdraws - Still, more mechanisms are actively being developed to improve the slippage-defense and losses in both directions 1. Without Strategist rewards, we lose a potential incentive for strategists to write strategies to connect vaults together with non-yield-earning strategies. - This concern is easily mitigated by the fact that strategists have a strong incentive to build out the non-yield-earning strategies because they maximize the opportunity for capital streams to flow into the vault in which generate their performance fee income. 1. More vault connectivity = more deployments = more costs - While this is true, many of the connective strategies are very generic and can utilize a minimal proxy pattern to deploy same-logic contracts