✅ [RFC] USDC Convex Meta Vault Deployment

Summary

This RFC would like to gather feedback around officially deploying our first Meta Vault product on Ethereum Mainnet to power the next product line of mStable.

This deployment would mark the cumulative result and effort of the last months of work within the mStable Builder subDAO, and mark the transition into further Meta Vault products down the line.

The purpose is to signal the imminent deployment, and with a subsequent proposal to hand over the control of the first Meta Vault to the ProtocolDAO and establish it as a part of the core mStableDAO jurisdiction.

Abstract

The Builder subDAO spent the better part of last year developing a 3Pool Convex Meta Vault, which in essence is a super powerful ERC-4626 token that allows for yield-capture of multiple underlying Convex pools, rebalances the positions at opportune times, and harvests & compounds the accrued platform rewards to holders.

Further information on Meta Vaults, in general, can be found in this blog post and this litepaper. For an exhaustive deep dive into our first Convex Meta Vault, it is highly recommended to watch this video from August that goes into great depth explaining the ins and outs of Meta Vaults, gives high-level information on the inner workings that make them tick, as well as answer most questions that could come up in relation to this exciting new offering.

First Meta Vault Strategy

The first set of mStable Meta Vaults are for staking a diversified set of 3Pool-based (3Crv) Curve Metapool liquidity provison (LP) tokens in Convex. For example, staking Curve’s mUSD3Crv LP token from the mUSD+Crv pool in Convex’s mUSD pool.

The Components

At the top level, the USDC asset is deposited into the Meta Vault and then invested in Curve’s 3Pool. The 3Pool LP token (3Crv) is then invested in an underlying 3Pool-based (3Crv) Meta Vault, which is another ERC-4626 vault with Curve’s 3Pool liquidity provider token (3Crv) as an asset.

The 3Crv is invested in underlying multiple Convex 3Crv Basic Vaults based on weights set by the Vault Manager. Withdraw of assets (3Crv) are first retrieved from the Cache, then from a Vault that is set as the L2 cache, and lastly proportionally withdrawn from the underlying assets. This may not match the weights set by the Vault Manager.

The Basic Vaults are ERC-4626 vaults that deposit Curve 3Pool LP tokens (3Crv) in a Curve 3Pool-based Metapool, eg: musd3Crv - deposits the Metapool LP token in a Convex pool; and stakes the Convex LP token, eg cvxmusd3Crv, for CRV and CVX rewards.

The Convex rewards are swapped for a Curve 3Pool token, eg DAI, USDC or USDT, using the Liquidator module and donated back to the vault. On donation back to the vault, the DAI, USDC or USDT is deposited into the underlying Curve Metapool; the Curve Metapool LP token is deposited into the corresponding Convex pool and the Convex LP token is staked.

The Liquidator module is responsible for collecting reward tokens from vaults, swapping them and donating back the purchased tokens to the vaults. In this strategy, this means collecting CRV and CVX rewards from the Convex 3Crv Basic Vaults and swapping them for DAI, USDC or USDT. The Liquidator then donates the DAI, USDC or USDT back to the Convex 3Crv Basic Vaults.

The following diagram shows the relationship if each contract.

Note:

  • For the Toplevel contracts we will initially start with USDC. DAI and USDT contracts can be added later.
  • Names and symbols are not finalised.
  • LUSD Basic Vault will be not added from the beginning, we might consider a replacement.

Motivation

After a successful audit of the 3Pool Convex Meta Vault smart contracts that were completed last week, it is now time to begin the process of involving Meta Governors in the final stages of release, beginning with this RFC to sanctify the initial approach towards a public release in Q4 2022.

The resolution of this first Meta Vault proposal would also set a precedent for future Meta Vaults, thus making it much easier to deploy them in a more agile and streamlined fashion down the line.

The deployment of the Meta Vault contracts and their release will happen in phases, and the formal proposal should be passed before the Meta Vault contracts are opened to the general public.

Pros

  • Show the world what mStable has been up to these last couple of months
  • Get the contracts deployed for pre-alpha and guarded launch prior to the official release ahead of time
  • Prime the ecosystem towards the new era of ERC-4626

Cons

  • It’s the first Meta Vault and therefore might be riskier than subsequent deployments, but this will be addressed with a closed alpha testing period that will commence soon.

Next Steps

It is suggested that the community comment on this RFC in the coming days, and bearing no significant opposition or change in ideation, we would move ahead with this RFC in the coming weeks and create a formal draft proposal on Github to be used for review.

Meta Governors are encouraged to provide as much feedback as possible until then, so we can create the best possible outcome for mStable and its users.

3 Likes

A question I have is around audits.

Specifically, what is the process for code review on subsequent Vault deployments? What code/contracts are now “done” and which would need to be reviewed by qualified individuals before deployment?

The call in August said that the contracts are intended to be modular, but without source code to review I can’t evaluate how much work it would be to add new Vaults.

I also think it’s important to make the audit available in tandem with the deployment (at the latest). Before would be better. There are business reasons to keep the source code closed until deployment, but I assume that the code will be made available as well.

Looking forward to the new stuff.

1 Like

Thanks for your reply!

The ideal would be that the majority of code can be reused. For subsequent Meta Vaults that would mean that if the functionality has been already reviewed, it does not have to be reviewed again. If we choose to change it, then that would add a bit of overhead. The majority of “new code” however would stem from the basic vaults, the single yield source wrappers. Using a similar convex strategy would result in the least changes.

Some of the contract components that can be reused for subsequent vaults are (non-exhaustive list, just to give a rough idea):

  • LiquidatorStreamFeeAbstractVault (capability to work with a liquidator contract and then stream the rewards over a period)
    • This contract is a combination of 2 capabilities: FeeAdminAbstractVault, LiquidatorStreamAbstractVault
  • PeriodicAllocationPerfFeeMetaVault vault periodically invests deposited assets into the underlying vaults and charges a performance fee.
    • This contract is a combination of PerfFeeAbstractVault, PeriodicAllocationAbstractVault, which in turn reuse AssetPerShareAbstractVault and FeeAdminAbstractVault respectivly.
  • Liquidator Contracts
  • Swapper Modules

Repo will be made open source at the latest with the publishment of the MIP. In that MIP we will also detail further the functionality.

In regards to the audit: The first audit we did was rather unconsequential, the source code changed since then more and the audit itself was not really helpful in finding real issues. The second audit will be published, but we need to wait for clarification to be resolved and a re-issue of a new report, then it can be made public alongside the repo.

2 Likes

Thanks a lot for this @dimsome, looks great!

What is there to say about this, other than I feel strongly to move this to a MIP next week, and then show the world what amazing things the Builder subDAO has been concocting up in the year and set a precedent of the powerhouse that is the Meta Vault product suite :sunglasses: :v: :partying_face:

Wow. Excellent job. Can’t wait to try it out!!

Will the MIP include the same diagram but with contract addresses existing underlying dependencies?

Yes the diagram will be updated to reflect the final pools, names and symbols. The addresses probably will be noted down in the MIP within a table I assume.

Thanks for the detailed write-up @dimsome :pray: Excited for meta vaults, mStable leading the way as always :rocket::sparkles:

2 Likes