Hey Mudokan, thanks for putting this together. I’m going to compile some of the elements team-side so it’s here for everyone to easily reference - rather than fragmented across discord messages.
- Everything seems to suggest that withdrawal fees are no longer the way to go. Additionally, we already went down ~90% in TVL - we made our keep from withdrawals already. We shouldn’t expect similar revenue metrics into the future.
- Generally speaking, it’s difficult to lower-then-raise costs to the user. Withdrawal fee removal is best done in tandem with new fee structure.
- A major consideration in the fee structure overhaul should be what the implementation costs look like. If new fee structure requires new pools, that means new code created by the engineers, new audits on that code, ample market testing in Beta… This is a process that takes months. We should do our best to situate the fee structure in a way where if extensive costs are required that it’s perfect and we don’t have to do it all over again.
Taking that into consideration…
Fee structures that are already permissable in current framework is ideal. Right now, we can use any combination of deposit, withdraw, and rebalance fees (rebalance = performance). We should also favor elements that can be added on rather than in replacement of existing framework.
Engineering did some research and interestingly… Yearn’s mgmt fee is actually accounted as in the same capacity as the performance fee. Whenever rebalance happens, they pull a set amount over time in addition to performance to get a management fee, unless the fee exceeds the yield earned, then all yield earned goes back to Yearn.
Current understandings suggest that we could fairly easily employ a similar framework by upgrading our rebalance function - no pool upgrades required. We could also make it more equitable than Yearn: 1% versus 2%, capped at 50% of yield versus 100% of yield (maybe we enforce a hard minimum APY of x% with no mgmt fees taken below the minimum APY).
I’m working to compile a comparison of our current fee structure and different mgmt, performance fees at different APYs and TVLs - how that translates to expected revenue and user earnings. That can help to inform an optimal base mgmt/performance fee structure. This also lets us handle Earn pools on equal footing to Grow.
IMO - this should be our basis for developing a more productive, composable, equitable, and predictable fee structure.
Then we can focus on what-else we can add on. I like the notion of a lockup of funds for reduction in fees. Everything I’ve outlined above is per-pool, and since vToken positions are fungible, we can’t do that outright, but I think we could treat such an option as a vVSP-style vault with long lockup. Perhaps you need to lock up TVL alongside vVSP to achieve the boost? Perhaps locking up TVL and/or vVSP gives additional VSP rewards or additional weight in voting on VSP awards?
On the flipside, there is meaningful discussion to be had on what happens to those fees once they are turned into revenue. I like the idea of setting revenue aside to purchase coverage on behalf of Vesper users (though need to understand scope - Nexus right now is OUT because they provide coverage per-pool, not per-protocol). What else?
Separately, we should talk about the road to implementing this stuff. If the first implementation ends at transfer over to mgmt fee, that still takes some amount of time to develop the logic and battletest. I think it would be a good idea to formalize a cadence - we know that zero fee pool xfers are coming. We could situate a timeline of T-0: intra-pool xfer fee waived. T+14(?): Conservative withdraw fees reduced to 0.1%. T+?? withdrawal fees replaced altogether with mgmt fee.
There’s been talks that we should try to standardize fees as much as possible. So I like the idea of mgmt fee capped on performance. (with base APY enforced). That way we can still more or less keep a scaling fee that grabs more value from higher APY pools without crippling lower APY.
