Re-igniting the Save Liquidation Discussion

[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

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 ) 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.

[Cold_Summer]

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:

May 21st Community Call Reaction

Additional ramblings: The Alchemix-style feature, which would effectively make us an Alchemix that also captures yield from swap fees (i.e. we should be able to outcompete them on risk-adjusted yield), would make mStable a “pseudo-bank,” really furthering that simple UI concept where savers could access some of their capital as needed, all while earning leading risk-adjusted yield–giving them traditional bank functionality except with an improved UX and yield/earning potential. Additionally, t…

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

[shubidoobi]

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.

[derc]

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)

[lonetree]

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.

[itsJeremiahS]

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.

[dimsome]

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.

[apricity0x]

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?

[dimsome]

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.

[naddison]

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

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

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

[dimsome]

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!

[naddison]

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.

[Javalasers]

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. 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).

[alsco77]

Great analysis!

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.

Can this be done? I’m not sure it can as they are all held in the same AaveIntegration. It’s not necessarily a bad thing to boost the APY by a high amount for a week… unless there is an easier method to tranche this amount

[naddison]

With the recent drop in COMP and AAVE prices, there is now only USDC 133k worth of COMP left. There is USDC 101k worth of stkAAVE.

COMP accrued
USDC                 37.87
Integration           0.00
Liquidator          494.76
Total               532.64     133,078.59 USDC (249 COMP/USDC)

stkAAVE accrued
sUSD                68.72
USDT               164.79
DAI                165.66
GUSD                22.21
BUSD                 0.00
WBTC                19.15
Liquidator           0.00 unlock Sun, 11 Jan 1970 00:00:00 GMT
Total              440.52     101,123.23 USDC (229 AAVE/USDC)

[Cold_Summer]

Thank you so much for your amazing work on this. Based upon the data you’ve provided, it appears we will be out of COMP in the next few months and then just left to liquidate COMP at the rate we accrue it. To be transparent, I’m not sure my smooth brain completely understands the stkAAVE liquidation mechanism.

That being said, the high-level vision I’d like to see for us is to liquidate & distribute less than we accrue each week, so we actually build an asset base that can generate cash flow → sustainable yield for the future.

Most yield aggs charge a 20-30% performance fee on the gov token farmed. So let’s say we distribute liquidations equivalent to 90% of the gov token we farmed the previous week–that still beats competition today. Then, we set aside 10% of what’s been accrued and add to Savers’ asset base to slowly grow that asset base. We deposit that asset base on Convex and generate yield from it. We then pay out that yield to savers periodically.

This cash flow from a growing asset base creates somewhat of a “war chest” for Savers to continue to earn leading yield well into the future. The issue isn’t our yields being too low today (see this discussion). The issue is more so that at current rates of liquidation & distribution of the liquidated assets, the elevated yield we are offering is not sustainable. This approach would secure better-than-market yields for Savers in perpetuity.

Given the complexity, I’m not sure the value add on the “smoothed out” yield is really worth the dev team’s time, especially since users will just accrue that smoothed out yield on an average basis over a reasonable time frame. So I’m not sure there’s huge value add to be captured there versus other things that are big hitters like v2 staking/Convex-style pooling & meta eth.

TL,DR The current route is unsustainable. Let’s liquidate 90% of the gov token accrued from the prior week, distribute that back to Savers and then keep 10% aside to add to an asset base (deposited on Convex or another leading yield platform) to produce cash flows to secure tomorrow’s Save yields. This balances yield today vs. yield tomorrow.

[naddison]

We are currently accruing around 10 COMP each week. At current prices, that’s only 2,300 USD a week, which gives the imUSD savers a 0.54 APY boost. Not liquidating 10% of the accrued COMP each week is only keeping 1 COMP so doesn’t create much of a “war chest”.
This is all subject to the COMP price. If COMP goes back up then the COMP can have a significant impact on saver’s returns. If COMP continues to fall then liquidating COMP adds very little to the saver’s returns.

[Cold_Summer]

Agree on all accounts as it sits today. I don’t think, however, this is necessarily about the numbers produced today, more about establishing a mechanism that ensures sustainability–sort of the cliche “process first” approach.

If we implement what’s discussed here, you’re looking at an order of magnitude more liquidity on mStable. Operating at that scale & reserving 10% per week, we’d be setting aside ~$5k per week in gov token, not ~$500. That’s certainly not insignificant. Add that to our current asset base and you’re actually able to generate some decent cash flow on an annualized basis for Savers if you’re farming on Convex with the mUSD.

If we’re sort of going to take the strategy that all these numbers are insignificant and running out of the asset base in a couple months is fine, that’s okay. I just think there’s an opportunity to save the asset base we have left, make it productive, and establish good process to retain our competitive edge even in a non-liquidity mining world.

Again, though, on the grand priority list perhaps this isn’t #1.

[Jeshli]

Formulaically Sell Off Non-MTA, Non-ETH, Non-BTC, Non-USD (AAVE, COMP, …)

• Connected to post: DAO Treasury management - #17 by Jeshli
• Deleveraging from other protocols (calculate the stable price and the farther that token is above, the higher a percent of holdings that mStable converts to USD,ETH,BTC).
• I would not buy tokens when their price was below stable value, but that would logically be the correct move
• I will return with an attempt to get these stable values for AAVE and COMP as well as the function by which I would suggest the protocol buy and sell by

[Jeshli]

Save yields here, ultimately just refer to converted to USD. This is less about now vs. future than it is about risk aversion. Asset allocation for users should be default provided to the user as liquidity rewards (as is done now on Polygon). Other than that then next obvious choice would be to default convert to USD/BTC but allowing the user to at least have a checkbox would be nice. What is more interesting to be is how to manage the treasury share of those rewards + any users that what to “follow” the mStable strategy. In due time, I will propose a formula for selling governance tokens aquired through liquidity campaigns according to a y=k/x like equation with derivative=1 at the “stable” reserve value of a governance token.