Re-igniting the Save Liquidation Discussion

PDP16, its approval, and subsequent discussion raised the following key points:

  1. Liquidating governance token rewards (COMP, soon stkAAVE) from lending out idle bAssets helps boost Save APY.

  2. The approval of the proposal led to the liquidation of $20k COMP per week (boosting Save APY by roughly ~3% per week according to @alsco77’s data in the PDP16 comments).

  3. Normalizing the other data provided by @alsco77’s to current conditions means we should currently be earning roughly ~$10k per week of COMP.

  4. Savers currently have $240k of COMP waiting to be liquidated.

  5. @shubidoobi suggested in the PDP16 comments that this COMP be turned into a productive asset used to generate sustainable yield for Savers.

  6. @derc suggested in the PDP16 comments that we have a flexible liquidation schedule based upon current Save APY.

Based on the implementation of PDP16 & associated commentary, I’m suggesting we explore the following perspectives:

We are currently liquidating more COMP than we are accruing each week. We need to take steps to ensure the sustainability of Save yields and improve capital efficiency. Let’s use the asset base we have generated (and continue to generate) productively to set a strong long-term foundation for the Save product.

I’m proposing a two-pronged approach to achieving the situation described above:

  1. Along the lines of @shubidoobi’s suggestion (which seemed to have support from @alsco77), I recommend that instead of depositing the mUSD generated from the liquidated COMP directly into the mStable Savings Manager, we should to use this mUSD productively to generate yield. I’m recommending that we deposit the mUSD into the Convex Finance mUSD pool, which is currently generating 18% APY, but I’m open to other options. We can then deposit the yield that mUSD generates from Convex into the Savings Manager, boosting Save APY with cashflows without reducing the asset base. If we continue down the current pathway (liquidating & distributing more COMP than accruing), we’re shrinking the asset base with which we can provide boosted Save APY. Instead, we should be growing that asset base (or at the very least treading water) and making those assets productive to provide a long-term, sustainable boost to Save APY and allow us to continue to offer industry-leading risk-adjusted returns.

  2. Along the lines of @derc’s suggestion, I also think we should consider flexible distribution of the mUSD generated from the liquidated COMP. I propose we should do something like “when the Save APY falls 1 std. dev. below its 7 day moving average, we start distributing liquidated mUSD.” This trigger condition is just an example–would need some technical support here. Since we’re currently accruing ~$10K of COMP per week, we can use some of that to supplement the yield as needed (using a mutually agreed upon trigger condition) while staying “net accruers of assets.”

Thereby we could boost Save APY by (1) distributing cash flows from mUSD earning yield on Convex (or another safe yield-generating platform) (2) situationally distributing some of the mUSD from the liquidated COMP in such a way that we stay “asset accruers.”

This approach would allow us to continue to generate attractive yields today, while growing the Save asset base, improving capital efficiency, and sustainably funding Save yields using cash flow for the long term. Larger asset base = more productive assets = more cash flows = more future yield for Savers.

Thoughts and feedback encouraged.


I think a broad spectrum of approaches are reasonable here. I feel like mStable is missing a higher-level vision statement of how it wants to prioritize:

  • Save yields today,
  • Save yields at some future time, and
  • Stability of Save yields (say) week to week.

There are trade-offs across these three, and your suggestion here implicitly nudges toward some kind of trade. But I am honestly not sure what the team or community wants Save to be “for,” and I’d like to have that conversation holistically to the extent we can rather than up/down voting any particular proposed step in this landscape in isolation.


Completely agree. I think currently we’re prioritizing “Save yields today” without the neccesary regard for “Save yields tomorrow,” but as you mentioned there are tradeoffs. A reasonable balance is achievable in my opinion (through some form of the pathway I described above).


I recommend that instead of depositing the mUSD generated from the liquidated COMP directly into the mStable Savings Manager, we should to use this mUSD productively to generate yield. I’m recommending that we deposit the mUSD into the Convex Finance mUSD pool, which is currently generating 18% APY

I’m wondering how long it would take to actually generate a noticeable amount of revenue to give back to savers. If the whole $250k of COMP was deposited there, and earned 18% in perpetuity, it would receive ~$865 a week, which wouldn’t be super exciting. However, if we are looking at a 5-6 year time horizon, we could end up with a pretty huge sub-treasury here earning funds on other protocols and contributing to the save yield. I would worry about not making the yields attractive enough to retain capital in the short term though.

@Javalasers Yep, this is the root of the question. Yields today/tomorrow/future, plus risk profile of savers, which plays a large role in determining what to do with the capital currently held by SAVE (if savers wanted, we could essentially lend out all the capital in SAVE to the convex strategy and end up earning an extra 18% base APY :exploding_head: ) While this would basically 2x capital efficiency, it would increase the risk profile of save given all funds would go to convex and then to curve. However, I think its a question that should be floated, potentially moving the current product more towards a saving instrument, and then deploying a second wave of mAssets that are solely for risk protection.


Yes, as Java mentioned, there are tradeoffs between Save yield today and in the future. My main concern is that the current scenario of liquidating more COMP than we are accruing means that we are setting up a situation where we will have a step-function drop in yield (and this situation is quite soon–less than 6 months, ceteris paribus), rather than a smooth short term drop to a permanently higher plateau (with potential for even some upside). Once this asset base of COMP is entirely liquidated & distributed, there will be nothing left to boost Save yields above competition, particularly in the situation where liquidity mining programs start to wind down. We could create a massive edge by planning for the future with less liquidity mining rewards. We’re currently forgoing all of those future cash flows by just liquidating and distributing, rather than funding Save yields for the future.

While we still have a bit of an asset base left, let’s think about slowly adding to that with a portion of the ~$10k a week we’re accruing, and creating cash flow from that growing asset base to fund Save yields in perpetuity to ensure our competitive advantage. Like I said, we’re on track to have a step-function drop in yields within 6 months and drastically limit our potential to generate future cash flows, hurting the Save product’s mid-term viability. There is some trade-off for yields today, but in my opinion, we should be setting ourselves up for success in a >6 month time horizon.

Regarding your risk profile comments and depositing all of the funds on Convex, doing so would inhibit the liquidity available for swaps, limiting our sole revenue source and feature that drives reflexivity within the product and value accrual to MTA. In that scenario, we’d basically just be a yield aggregator and the optionality/capital efficiency/reflexivity of mStable would be missing. I think you do raise a good point about allowing Savers to chase higher yields and have more of a granular control over their risk with where their idle bAssets are deposited. I discussed that here:

Overall, great discussion. These are the types of things we need to be thinking about to take mStable to the next level. Love it.

Thanks for bringing this topic up again, and most was already mentioned here, but since I commented on this previously, I wanted to chime in again quickly:

I completely agree that we’re currently focusing most of our attention on the “save yields today” approach, which is fine in my opinion, and as @alsco77 mentioned, a line needs to be drawn between withholding potential yield from savers (to some extent it is our obligation to steward the best yields for savers that trust us to handle their account the best way possible), but I am also weary as before around the inherent shortsightedness of taking more out than putting back in, without any plan to correct this course of action at all for the foreseeable future.

Compound liquidity mining will end in a little over 4 years, and if we do not take any action at all, we might have provided the best yield up to that moment, but in the process will have lost an opportunity for sustainable high yields forever, at least in regards to liquidating COMP and stAAVE.

Even if we started out very conservatively, and only allocated 1-2.5% of all farmed COMP and stAAVE to the treasury for future accumulation and ability to participate in governance, staked 2.5-5% on the platform directly, and then liquidated an additional 5 to 10% into mUSD or MTA for additional yield-farming opportunities, or to simply boost the Buyback & Make pool further, we could set a precedent of taking action against time and safeguarding against the inevitable end of those yield farming opportunities in a super conservative way.

This could be further customized by turning the feature on/off with higher/lower numbers with the dynamic approach @derc suggested, which in return would barely hurt the savers today, but ensure that they and their children in the future could still enjoy high yields on mStable that can compete with the rest of the industry. I firmly believe we’re building a generational product, similar to Synthetix, Compound, and Aave, and we should treat it with as much care and respect as possible to make sure it can keep flying towards its destination safe and sound.


Enjoyed the discussions above.

It could be weighted more towards like Anchor, with yields floating around a target APY. I think Save on its own is a fundamentally powerful and simple to understand product and MTA can be used like a voting proxy to channel where yields should go autonomously (similar to veCRV)

1 Like

This discussion is fantastic. It’s bit of a doozy as it touches on a few major points ([1] SAVE’s philosophical purpose, [2] how to efficiently handle our COMP faucet given its timeline, and [3] if we do decide on changes where and how those funds will be put to use), so it might be worth considering breaking these out into separate discussions, but either way, this is some great conversation.

On the note of [1], I think if we’re leaning deeper into the idea of having the premier, risk-adjusted savings account in all of DeFi, then I would be of the opinion that we prioritize longevity over immediate, higher yield. There are lots other protocols and projects that folks can place their money in to receive a higher yield than SAVE, but individuals that choose SAVE over others do so (IMO) because its the safest, most reliable, and most consistent return. Arguably, it’s the same reason people use Anchor on Terra. I think positioning SAVE in this way makes the mindset switch from a traditional savings account with a bank or centralized entity to SAVE on mStable an easy one. We’re not offering your latest and greatest (and riskiest) yield you can find, we’re offering safe, long-term, passive growth on your stable assets.

All that being said, I think there’s a balance that can be achieved between being more capital efficient with our assets that generate yield for our SAVErs, and ensuring its long life-span, which leads me to [2].

I really like the ideas presented by both @Cold_Summer and @shubidoobi to more efficiently handle our COMP liquidation funds. I would hope to see that at the very least we do perform some % alterations to where and how the funds are being used (something along the lines of Shubi’s idea) to help extend our COMP saving’s lifeline. And within that % allocation, I think it also makes sense to allocate some amount to a more yield-focused approach, building upon those funds further and using them to generate additional yield via other protocols in the ecosystem (Cold’s idea). What jumps out at me between both approaches however, is that there is some room to be more efficient with our COMP liquidations without stepping on the existing yield provided to SAVErs today.

I do want to touch very briefly on point [3], however, I think this could really be a whole discussion in it of itself. Ultimately I’m not opposed to the Convex idea, but as I was reading through this I had the thought that perhaps by providing liquidity to Curve, we could be taking away potential swap volume if aggregators start selecting the Curve mUSD pool due to the increased liquidity. Granted, we’ve decreased the swap fee as of PDP22, but I wanted to raise it in-case its something worth considering (it very well may be moot point).

In the spirit of contribution, I also wanted to throw out another idea for that yield-focused % allocation: which would be to swap the funds for LUSD and then supply that LUSD in a Liquity LUSD Stability Pool. I think this approach has a couple of interesting dynamics:

  1. First and foremost, this gives the SAVE product a hedge against the market taking a downturn. Most yield generating opportunities bloom with the market’s growth, but not all of them will generate good return when the market cools down. Supplying to the stability pool will earn the “sub-treasury” LQTY tokens (at current APR of ~35%) but more importantly, it will receive in proportion to the % of the pool supplied, its share of ETH that’s liquidated across the protocol. If the market experiences an unfortunate cool-off period, we’ll actually be able to take advantage of that time and start growing a sub-treasury of ETH, which in turn could be liquidated further to keep a stable yield during a bear market.

  2. If we end up continuing with the feeder pools and implement an LUSD/MUSD fpool, then we can actually perform the swaps from mUSD to LUSD using our own liquidity contracts! This of course generates fees for those that LP to that fpool, which I think adds a nice reflexive touch to this strategy.

(Full disclosure, I own both LQTY and LUSD, but as I hope you’re aware this is not me shilling my bags here, this is a suggestion that I think holds water as a potential option for the benefit of the protocol)

Regardless of the route we choose going forward, I completely agree that there’s opportunity to use the assets and COMP liquidation funds in a way that both can increase SAVE yields longevity, while not entirely consuming one of our major faucets for the yield itself.


Love this discussion and wanted to chime in from a more high-level point of view.

IMHO The key to a successful crypto protocol/product is to be able to survive market cycles.

If we can take the steps needed today to ensure longevity and stability of SAVE returns independently of market conditions, that has the potential to draw in a lot of new folks who currently see crypto as a ‘get rich quick scheme’, attracting the associated liquidity and creating more trust in the protocol.

I think it’s a safe bet to assume that crypto neophytes will look for low risk and predictability in returns when joining DeFi rather than the highest possible short-term gains on unproven protocols.

The other key is to make participating in mStable more accessible to those with little or no experience in crypto, I’m starting an informal proposal to that effect in the community chat.


Thanks for posting this! I think this conversation is very due and now is a very opportune moment to reignite it, with the launch of mStable earning stkAave.

I don’t think it would be fair for savers to communicate that we take another cut from their yield (we already take a cut for the Buyback and Make Strategy) and use it to generate yield in the future. The Users of SAVE are not a homogenous bunch. They all have different interest and time horizons.

You all also provide a good point that we as mStable have to think long term. While we could just ramp up liquidation, burn through it and have a very good interest rate for the short-term, we probably shouldn’t!

I think it would be good to to use the farmed assets to generate additional cashflow and only liquidate as little as it is necessary. For this I will be proposing a new mechanism for liquidating assets:

Average out the interest rate of SAVE of the previous period and boost it up with liquidating assets to a certain degree. This could be either set as a target APY, or APY above the rate of what Aave. Bringing in a bit more predicability and stability to the yields.

1 Like

Great points here, although looks like we need to get clarity on the direction / what to put up as a vote. @Dimsome how close are we to put this to vote?

Yes, we need to have a discussion on the exact mechanism and also what is viable from a developer’s standpoint. Would love to chat with a developer to see what is possible and to reality-check my ideas.

1 Like

I’ve pulled some stats on the COMP liquidations to help with this discussion

20K USDC worth of COMP has been liquidated each week to boost the imUSD savings by around 4-5% APY.

With drawing down the COMP reserves and the recent fall in the COMP price, we only have around 10 more weeks before the COMP reserves run out. This assumes the current COMP price.

It’s relatively easy to reduce the max 20k USDC liquidation amount of COMP that is liquidated each week. That just requires a protocolDAO multisig tx to update the liquidation. In fact, as we are upgrading the Liquidator contract the the liquidation of the COMP needs to be recreated which means now is the perfect opportunity to change the 20k weekly USDC amount.

So the immediate question is, what should the max amount of COMP, in USDC terms, should be liquidated each week and streamed to the savers? Some options are:

  1. Keep the current 20k USDC
  2. Return to the original 5k UDSC
  3. Use another USDC amount

I looked at being more dynamic in calculating how much COMP should be liquidated each week. Trying to look as historical saving rates and boosting with COMP liquidation if below a set level is tricky to do as the contract doesn’t know what past save rates were. We’d have to store those which is expensive on gas.

It’s also difficult to predict what future imUSD saving rates will be as it depends on the amount of swaps/redeems and the variable platform interest rates.

The simplest change to make the liquidation more dynamic would be to calculate the amount of COMP to liquidate based on a percentage of the total savings. eg we cap boosting the savings rate to 4% APY of the savings pool. This requires a contract change so is not trivial to do but it is doable. It would require getting the total supply of imUSD tokens and then calculating the weekly amount to achieve the set APY rate.

My recommendation would be to not change the liquidator contract and to just change the max weekly COMP liquidation amount in USDC terms on the existing contract.

It’s also worth considering the stkAAVE that has been accrued. The liquidation mechanism of stkAAVE is different to COMP and currently can not cap the amount that is liquidated each week. It just claims all the stkAAVE it can in the first week and then sells it after the 14 day cooldown. For this reason I’d recommend enabling the liquidation of stkAAVE for the mUSD bassets sUSD, USDT and DAI over separate weeks so the savings boost to imUSD is spread out more evenly.

Below are the current amounts of stkAAVE that can be claimed for each of the mUSD bassets
Screen Shot 2021-06-15 at 4.52.43 pm
So if we claim the stkAAVE from USDT, the save rate would be boosted by 9.92% APY for the week the liquidation is streamed.

Here’s the amount of stkAAVE that can be claimed for the mBTC savers
Screen Shot 2021-06-15 at 4.53.43 pm
Once the liquidation contract has been upgraded, this can be claimed by creating a liquidation of the WBTC integration.

There isn’t much stkAAVE to be claimed for the GUSD Feeder Pool vault holders
Screen Shot 2021-06-15 at 4.57.38 pm


Great discussion so far! The main sticking points so far are:

  • Trade of between boosting SAVE yield now versus a long term strategy of value accrual
  • Dynamic approach more sensible, rather than liquidating the same amount every week.

The conversation so far has some great points that helped me to conceptualize the following ideas:

Minimum Viable Liquidation (MVL)

I this regard, I would like to coin the term Minimum Viable Liquidation (MVL) as a possible approach. That means we liquidate as little as necessary to maintain the highest amount of value-generating and appreciating assets, while still liquidating enough so that the yield for SAVE is attractive and/or outperforms third-party lending platforms.

For this approach we can think of 3 different mechanisms:

1. Set Floor target APY with overshooting


  • Liquidate enough to fill a distributor contract with stable coins but not distribute yet.
  • Set a Target APY
  • Calculate the APY (lending protocols and swaps) over a set period (1 hour, day, or week)
  • Boost up the APY with the distributor contract in the next period
  • Replenish distributor contract if necessary.

2. Set Floor target APY without overshooting


  • Liquidate enough to fill a distributor contract with stable coins but not distribute yet.
  • Set a Target APY
  • Calculate the APY (lending protocols and swaps) over a set period (1 hour, day, or week)
  • Boost up the APY with the distributor contract in the next period
  • If the APY is above the target, use the overperformance to replenish the distributor contract
  • Replenish distributor contract if necessary.

3. Set Target APY booster


  • Liquidate enough to fill a distributor contract with stable coins but not distribute yet.
  • Set a Target APY above the underlying
  • Calculate the APY (lending protocols and swaps) over a set period (1 hour, day, or week)
  • Boost up the APY with the liquidated basket of stable coins in the next period
  • Replenish the distributer contract if necessary.

The goals here are:

  • to conceptual the ideas a bit more with visual aids, since we are talking always in the abstracts
  • To smoothen out the APY and make it a bit more predictable
  • To liquidate as little of appreciating and cashflow assets as possible (Nr. 3 might be the one solution that liquidates the most and the others are dependent on the Set APY)

A few remarks/disclaimers:

I am aware that the APY from the underlying protocols and swaps are only historical. But if we calculate it more granular, it might smoothen it out more evenly.

Also, I am aware that these graphs are ideal cases, the APY Save in reality would be somewhat delayed.

Open questions:

  • Are any of these concepts good? And if so, which one would be the best?
  • Are we earning/farming any other assets? (besides stkAave and COMP)
  • What is the COMP to stkAAVE liquidation ratio? 50:50 or do we have a better approach to this?
  • Is any of this from a smart contract dev possible/feasible?

Looking forward to your ideas and feedback!


Thinking about is some more, I think the best way to get the historical savings rate is for the liquidator to store the current price (exchangeRate) of the imUSD contract. When the liquidator is executed in a week’s time, it can calculate what the average APY was for imUSD over the week. The liquidator would also have to store how much was liquidated last time so it can remove that from the savings rate. That is, the liquidator just calculates the APY earned from swap/redeem fees and platform interest. The liquidator then assumes the next week will be the same and liquidates enough rewards tokens to bring the estimated savings rate up to a set minimum level.
But there are a few issues with this approach:

  1. Storing the last imUSD exchange rates and liquidation amounts adds a lot to the gas costs of the already expensive liquidation process.
  2. The assumption that past rates will match future rates is weak. The amount of fees earned from swaps and redeems is variable and largely depends on market volatility. The amount of interest earned from the platforms like Compound and Aave are also variable. This means the savings rate would still overshoot or undershoot the target APY.
  3. This approach does not flatten out variability of the savings rate day to day. One day could still have little to no returns, while another day could be well above average.

I’m not aware of other rewards tokens that we are not claiming besides stkAAVE and COMP.

At the moment, there is no liquidation ratio between COMP and stkAAVE. They are separate liquidation processes and are not aware of each other.

1 Like

I like this breakdown. I think I favor a picture that’s closer to #3 (Set Target APY booster). I think that #1 is more generous to savers than necessary when the underlying yield is low. And I think that #2 will be optically bad when the underlying overshoots and may cause people to churn out of the platform as a result.

The particular implementation of #3 that makes sense to me off the cuff is: cap the max COMP and stkAAVE liquidation over a time period to be the lesser of:

  • Some constant fraction of the tokens accrued during that time, with this fraction controlled by mStable governance. [Say 0.8]
  • The amount of tokens required to be sold in order to increase USD-denominated Save yield APY by X% for the time period, with X again controlled by governance. [Say 2%?]

In this way, from the POV of a Save user the invariant is clear: “I’ll always have a higher APY on my native yield vs. the underlying protocol. This improvement will cap out at 2% (in the example above), and may be less. But if I’m looking to park and forget, and if all I trust is native yield, then this is clearly better than just using raw Compound+Aave.”

…and from the POV of mStable’s treasury and long-term health, some other invariants are clear: “we’ll always divert at least 20% of the underlying platform tokens to the treasury. And in times where the price and/or emission rate of those underlying platform tokens goes up, we’ll generally divert more than 20% of the underlying platform tokens to the treasury.”

I’m writing in haste and haven’t had time to think too deeply about this. All numbers completely made up for sake of example and should not be anchored to. :slight_smile: I also would suggest we directly compare how this would stack up to any existing other protocols that have these dynamics (yearn vaults? balancer v2 can also apparently lend out idle assets to Aave and similar).

1 Like