Deposit idle mUSD in the mStable Savings Contract (ETH Mainnet) to the Iron Bank

Posted by Dove Mountain on behalf of C.R.E.A.M. Finance

Summary

In an earlier forum post Capital Efficiency in mStable it was discussed – and agreed upon by the community – that there’s an opportunity to make mStable more capital efficient by depositing idle assets.

We would like to build a formal protocol-to-protocol working relationship between C.R.E.A.M. Finance (Iron Bank) and mStable, where the Iron Bank services mStable’s idle assets. Currently, the Iron Bank supports mUSD and has plans to add mBTC shortly.

I propose that mStable lend out a percent of the idle mUSD in the mStable Savings Contract (ETH Mainnet) to the Iron Bank.

Motivation

The mStable Savings Contract currently holds $25.3M mUSD and 131 mBTC. This capital should be put to work to earn more money for holders.

Once idle funds are deposited in the Iron Bank, we will work closely with the Iron Bank yVault strategists to ensure immediate usage of the mUSD (and eventually mBTC).

Safety is a top priority for the Iron Bank.

To illustrate this, here are the security measures the Iron Bank has recently taken: Trail of Bits Audit, 83% DeFi Safety Score, $1.5M bug bounty, and code peer-reviewed by Yearn team. Additionally, I feel it is important to note that no contract from C.R.E.A.M. Finance has ever been compromised / no users funds have been lost.

Next Steps

Snapshot vote - to deposit % of mUSD in mStable Savings Contract to the Iron Bank.

8 Likes

Super excited for this, I love any ideas of a protocol to protocol collaboration and CREAM has definitely brought lots of innovation in this space, and together with yVaults strategists I think this is a great opportunity to earn a more competitive yield on some % of idle mUSD/mBTC.

1 Like

Hello Max, thanks for your proposal!

Protocol-to-protocol is a very new concept and there is so much potential in this. I think it’s great to increase the capital efficiency of mAssets in SAVE and make it an even better product offering a higher yield.

I think there are a couple of considerations to make:

  1. What strategy is going to be implemented? You might say that it doesn’t matter, but I would argue that it is very much in the interest of mStable to only employ a strategy that benefits MTA token holders and the mStable products. For example, A strategy to farm and sell MTA would not be in the interest of MTA token holders.

  2. What percentages should we initially propose? In the beginning, we should aim for something conservative and ramp up over time if all goes well.

Eager to hear your and the community’s thoughts on those two points.

The next step would be to put this into a formal MIP. You can find all the MIP here
You can find more details about our Governance process here.

Let me know if you have any questions!

Apologies for the basic question but I just want to ensure my mental model is correct… The $25.3M mUSD in the Save contract today as an example…those mUSD themselves are backed (very nearly) 1:1 with bAssets (USDC, DAI, etc.), and the backing assets for those mUSD are themselves partly deposited in Compound and Aave today, with some kept in standing pools for use in mStable Swap. Is that right?

And this proposal wouldn’t change any of the above, but would also take the mUSD themselves from the Save contract (or some fraction of the mUSD in Save), and deposit those at Iron Bank, earning interest at that level also. Is that right?

Mechanical question first: what would the liquidity/availability of mUSD within Iron Bank be? Today if there’s a “run” on the Save contract my understanding is that all mUSD are directly on hand in the smart contract and available to pay out depositors 1:1 immediately. Would that change?

More abstractly, something seems slightly too good to be true about the double layer of interest here. As a silly example, one could imagine Iron Bank depositing the mUSD into Save, which would then deposit some fraction of those back into Iron Bank, etc. etc. And of course this would more likely happen indirectly, with IronBank loaning out the mUSD that circles back into Save from some user
There’d effectively be some kind of levering up in this case, and while I know this picture isn’t the intention, it gives some flavor of what feels a bit odd to me about this.

Defi magic is wonderful right up to the point where it becomes wild / scary / too-good-to-be-true, and we all have different sensibilities about where that point is of course. :slight_smile: I have not studied financialization of other instruments very closely, so perhaps there are a bunch of real world analogs to this that can build comfort and intuition(?).

3 Likes

So, if a portion of mUSD would be locked up in another place, how would this affect the ability for a user to withdraw? I’ve seen some pretty big withdrawals in the stats page before, like 20M in one day. Would this add friction or a delay to people wanting out of the Save contract?

3 Likes

Looks like javalasers has some of my same concerns.

Hi max, glad to see you here, and cool to see how far Cream has come in very little time.

Basically, I don’t want to harp too much on what has already been said, so I’m only going to add that I’m curious to hear your figures on what leverage (because it ultimately will be some form of it) you’d deem as save, and if there would need to be certain backstops implemented on contractual side, to only allow for x% on a daily basis to be withdrawn from the Save contracts to prevent a cascading escalation.

Also, I noticed on the Trail of Bits audit that your fallback oracle was centralized for some assets, and that the Comptroller Admin address has the authority to replace the oracle at any time.

Has this changed since the audit, and would this affect our own mAssets deployed, and what is the short to medium-term outlook for this point and overall stance on decentralization by Cream? Is the admin addressed governed by a multisig, or how exactly does that work in-house if you don’t mind me being nosy here? :grin:

Once again, great to see more cross-protocol collaborations coming together, and happy Friday!

I would like to see this happen, however, I think that only the mAssets available in feeder pools should be used in phase 1, given that this does not directly affect the risk profile for SAVERS.

Atm there is ~$5.5m mUSD and ~140 mBTC available in fPools that could be earning interest in CREAM.

Additionally, possibly 10-20% of the mAssets backing imUSD/imBTC could be deposited there… I would prefer to introduce as little risk as possible to savers. To answer a point from above, I think that this introduces very little risk for redemption availability.

Questions:

  • What kind of yields could we expect?
  • Where would the prices come from for mAssets, given that they have no significant CEX listings? Would this affect the risk profile of our deposits?
  • What kind of utilisation rate would we expect? It is important to have no higher than say 70-80% utilisation to allow for swaps/redemptions to still flow nicely.
1 Like

Good to see the conversation in here. @Javalasers thank you for bringing up some very valid and rigorous points around mechanics of the proposal on chain (it has cleared up some questions I had) and how it will affect levels of risk in the system.

DeFi certainly is magic, and part of why its valuable is because its allowing us to build away from the old models in tradfi that compounded and then obfuscated those same risks. It is in our ethos to build better.

I would love to hear an update too from @max1 in regards to @shubidoobi question around the TOB audit.

Overall, I am strongly in favour of collaboration, I think the design space for ways mStable and CREAM can work together is quite big, and that the questions is how we collaborate and not if.

I admit that after some reflection I prefer @alsco77’s take on how deployment of mUSD in feeder pools could well be superior in managing protocol risk. So am backing that idea, it wasn’t something I’d considered and I feel its very elegant.

Up only folks, excited to see this proposal go live in whatever form it takes :rocket:

1 Like

Great point @shubidoobi

As a C.R.E.A.M. Finance team member, I can provide some context here:

  • We use Chainlink as our price oracle, and most of the major and stable tokens are covered by Chainlink as written in our docs (https ://docs.cream.finance/iron-bank/price-oracle)

  • We are working closely with Chainlink to make them cover all of the Iron Bank listed tokens, including mUSD

  • Those tokens without Chainlink support are covered by our self-built oracle controlled by multisig

As far as I know, Chainlink has their own standards for price feed evaluation. The so-called “decentralized secure price feed” is composed of many conditions, including on-chain liquidity, holder distribution, trading volume, listed in CEX… etc.

In Iron Bank, we have most major and stable tokens live up to their standards that allow us to use Chainlink as our primary price oracle. However, while we are steadily increasing our markets, some tokens like mUSD is the market that we are really interested in but not supported by Chainlink.

Thus, we are working with Chainlink closely to get their support on these tokens, to increase Chainlink’s support coverage on Iron Bank. At the same time, we use our self-built price oracle to strike a balance between development and business. Thought it’s like simply filling up the gap, we do have our own security measurement to build up the whole structure that enables the whole Iron Bank.

Reference:

  1. Iron Bank market performance (https ://app.cream.finance/markets?protocol=Iron%20Bank)
  2. Iron Bank technical documentation (https ://docs.cream.finance/iron-bank/price-oracle)

Sorry about the link. I have to cut them apart to submit this post.

4 Likes

Innovative collaboration like this would definitely be beneficial to mStable and allow us to continue to offer industry-leading yields to go along with our signature composability. I would like to echo @alsco77’s suggestion of starting with fPools and agree that we should ensure the utilization rate is capped at a level that ensures redemption liquidity, which also helps address some of @Javalasers and @trustindistrust concerns (which I also shared on initial reading).

4 Likes

Thanks a lot for the throughout explanation eason, it’s much appreciated! Really insightful, and I can see that there is only good intentions at work here, and it feels like a common goal to get this moved to Chainlink :blush:

Also many thanks to @alsco77 for the insights on our side, feels like this could really work out quite well, and am excited to see this unfold further now :+1:

2 Likes