[RFC]: Restart Enzyme vault & diversify ETH across staking providers

[BraveNewDeFi]

@elisafly

The Maple strategy was not one that we proposed and our mandate was to write the code to bridge the two protocols and then to execute on the MPL yield strategy that was initiated by the community. We were not tasked with actively monitoring or managing the portfolio on a discretionary basis but in hindsight, it would have been a valuable service given how the pool concentration changed.

Thank you for the clarification! It’s important context, and I know a few members shared that they thought Avantgarde was actively monitoring the Maple position for the mutual, so I really appreciate the clarity here

@elisafly

I understand your concern here but for context, the Enzyme cover in question was purchased by Celsius before they filed for bankruptcy. It was for a vault they managed which subsequently they had to close due to the bankruptcy procedures. We can either delist enzyme insurance from Nexus or limit it to a much smaller number (eg. $2-5m). Also I believe the Celsius exposure rolls off in May and will not be renewed. In any case, there shouldn’t be a reason not to increase AUM up to 20% of the Capital Pool over time as long as we are aware that we have to limit exposure on the protocol insurance side…

My comment wasn’t about the Celsius cover buy per se, but just best practices wrt to risk management. Since the mutual would be exposed to Enzyme v4 smart contract risk, providing cover for that risk would potentially amplify losses should an exploit occur. Having 20% of the mutual’s capital in an external smart contract and then allocating to other strategies with smart contract risk creates additional exposure to risk. The more smart contract layers, the more risk the mutual is exposed to.

@elisafly

To answer your question more directly, we do not foresee the need for the involvement of the Mutual’s Engineering Team, which can stay 100% focused on the current priorities at hand.

If there is a proposal to increase the ETH allocation to the Nexus Mutual Enzyme vault, then there would be some need for their involvement since the capital pool cannot send out funds without smart contract work being performed. If the allocation remains as-is, then I don’t believe the Engineering team would need to be involved, but I’ll leave that to @Hugh or someone else from the Foundation team to confirm.

@elisafly

One additional question I have is whether Nexus DAO would like us to take on a more holistic role and monitor the entire risk of the DAO regularly. This is something not currently proposed in the scope of our work. I’m thinking it might be useful to have periodic reports (eg. monthly) which highlight how the exposure has changed based on new premiums sold, current cover exposure, positions rolling over. Together with that, we could provide recommendations necessary for the DAO to remain within its risk thresholds. For this extra assignment it might make more sense to explore a fixed monthly fee (vs. AUM based).

Currently, the DAO R&D and Marketing teams are working on Dune Dashboards that track cover exposure in detail, as well as analytics about staking across the various staking pools. Previously, members voted to end an ongoing partnership with dedaub due to cost and its impact on the DAO treasury holdings. You can read through the Reviewing treasury expenditures | Dedaub smart contract monitoring service for more info. My educated guess would say the potential for Avantgarde to do this would be highly dependent on the fixed cost and how Avantgarde would focus on risk (e.g., changes in risk at the smart contract layer or changes in overall exposure to risk based on cover sales?). The protocol does have risk exposure limits and the Advisory Board is able to change certain parameters to better control exposure to global risk levels should risk change quickly for certain products. You can read more about capacity controls in the docs.

Overall, I just want to say that I appreciate your responses and the clarify you’ve provided, @elisafly