[preMIP] IAM for Surplus Buffer

Situation

The Surplus Buffer is the instrument within the Maker-Protocol to reduce the amount of flaps (auctioning DAI when the Protocol runs profitable) and flops (auctioning MKR to compensate for bad debt or expenses). It also provides some kind of safety net on large market downturns to compensate for loss on the protocol to avoid minting DAI when the general sentiment on crypto is bad, the MKR price therefore low and the amount of MKR minted unreasonably high.

It is a parameter controlled by Maker Governance. Historically, we have always tried to keep the parameter to a certain percentage of DAI in circulation - usually between 1% and 2%. We did this in several executive votes (see corresponding Signal Requests here).

Complication

There are several circumstances that makes controlling the instrument more and more complicated

  • We have a lot of different collaterals by now. Some of them will probably stick with the general rule of 1% of DAI minted from this collateral, while others may need different values: DAI from PSMs should probably not affect the Surplus Buffer at all
  • DAI supply from non-stablecoins has increased a lot - 13% over the last week, 93% over the last month, 1000% over the last year (live numbers can be seen here)
  • Fueled by rapid growth of DAI supply we have two conflicting sentiments: “raising the surplus buffer to keep the Surplus Buffer in line with the supply” and “we need to finally start burning MKR again”.

Resolution

I want to propose that we introduce an Instant Access Module that would allow any user to adjust the Surplus Buffer based on parameters decided by Maker Governance. We already have a similar mechanism in place for adjusting the Debt Ceiling for vault-types.

I would like to kick off this pre-MIP discussions with the a proposal of dimensions that would need to be part of this new IAM and would be under control by Maker Governance:

Target Surplus Buffer

For each of the vault-types ilk we set a desiredBufferPercentage which is the amount of Surplus Buffer we would like to have based on the DAI-supply generated by all vaults of this vault-type.

Additionally, we introduce a system wide riskAppetite multiplier (>0, <=1), that adjusts the Target Surplus Buffer. The Target Surplus Buffer for all vault-types combined could be expressed as

riskAppetite * \sum desiredBufferPercentage(ilk) * daiFrom(ilk)

Example: Let’s assume we just have two vault-types: ETH-A and USDC-PSM

ilk dai generated desiredBufferPercentage
ETH-A 100,000,000 2%
USDC-PSM 100,000,000 0%

The Target Surplus Buffer would be (100,000,000 * 0.02) + (100,000,000 * 0) = 2,000,000 DAI

Growth Rate

As many think the Surplus Buffer is far too low from a risk perspective but we don’t want to stop burning completely, we need a way to limit the growth of the Surplus Buffer. The easiest thing that comes into my mind is that we introduce a new parameter that sets the percentage of change possible related to the difference of the current and the target Surplus Buffer within a defined timeframe.

Example: Assuming we currently have a Surplus Buffer of 1 MM and the Target Surplus Buffer would be 2 MM and we have the growth rate set to “1% per week”. If the last increase happened exactly one week ago, calling the IAM would result in the Surplus Buffer to be set to 1,010,000 DAI.

Decrease Rate

Same mechanism as for the Growth Rate - but I guess we want to be able to set a different rate here.

Next steps

Even if my idea is immature or super bad or very important parts are missing, I hope we get some discussion going on. At some point the discussion might result in a MIP. Happy to hear your opinions and even better ideas!

Edits

  • 2021-11-17T23:00:00Z suggestion by @LongForWisdom about a global riskAppetite multiplier
13 Likes

Thank you so much for putting this together Schuppi, long overdue :smiley:
Can’t wait to see this implemented.

1 Like

Awesome proposal! And especially that the target is based on a percentage of each vault type.

Regarding the growth rate of the surplus, is there any technical difficulties to set a percantage of the stability fees collected here? For instance if the system surplus is below target for one vault type, 70% of stability fees for that collateral is used to increase the system surplus until the target is reached?

Some thoughts:

  • I think you would want a global ‘risk appetite’ multiplier as well, such that governance can modify everything proportionally.
  • I think any automatic system probably shouldn’t adjust the buffer downwards. I can see lots of cases where losing total DAI minted is a result of some major problem that might require us to keep the existing surplus and not automatically sell for MKR to burn. Feels like manual decreases might make more sense?
  • I suspect we should handle ‘growth rate’ by lerping the global multiplier parameter I mentioned up front. This would let us decide things in the form of ‘aim for surplus equalling 3% of risk-weighted assets by 2025, or somesuch.’ I think this would make things simpler.
5 Likes

Hmmm maybe I got your intention wrong - but isn’t the growth rate doing something similar though on total and not on ilk level?

1 Like

Good idea, will add this to the post later.

The decrease rate can just be set to 0 at the beginning (and maybe stay there permanently), but maybe there is a case where it does make sense to have this used…

We could add a lerp in front of it :wink: parameter lego

2 Likes

An interesting discussion for sure. The decrease rate has some potentially interesting implications that it’s worth thinking about.

If there’s a market crash and we drain a portion of the stability buffer leading to a corresponding drop in the Target Surplus Buffer we would have an opportunity to possibly have Flaps at a lower MKR price as we refill the buffer. This could theoretically burn more MKR (for this to work the MKR price would need to follow ETH/WBTC in a market crash - which I suspect it largely would but you can never tell in crypto).

Obviously, a counter to this is that the worst time to decrease our buffer is after a market drop in case the market keeps dumping. Interesting to think about though.

Maybe we should keep a “war chest” of Dai funded from fees but separate from the Stability Buffer that could be used to Flap after an x% price drop in MKR to enjoy the best of both worlds.

Actually might be worth to add another parameter that reduces the target surplus buffer (0 in the beginning) to take account any future treasury we keep outside the system surplus?

Yes, I agree that it is similar as long as SF levels are not changed. If I understand it correctly(?), with your example of 2% desiredBufferPercentage and for instance an SF of 3% on that vault type the 1% per week growth would lead to ~35% of the SFs being used to fill the buffer (2%*1%*52/3%). If the SF was changed to 2% this would change to 52%. So maybe we then need to consider if the growth rate should be changed when SFs are changed?

I like the idea!

Not quite sure I get the specifics. My interpretation:

Use Risk’s asset specific weights to derive the implied portfolio risk weighting, R%. Then contribute X% of profits to Capital Surplus until it reaches R%. And burn (1-X%) Once it reaches R%, then burn a higher percentage than before and contribute the remainder to Capital Surplus.

The other value is that Maker would also now focus on the R% and its associated components which are provided by Risk. And the underlying Risk methodology to generate the weights. Then we would be arguing about how to measure and manage risk, which I view as a definite improvment…

1 Like

Thanks for putting this together, a very important subject.

I would request @Risk-Core-Unit weigh in on metrics to determine - seems they are focused on CET1 Ratio (Equity / Risk Weighted Assets) but if leverage/liquidity ratios are relevant we should use a combination.

IMO, burning decision should be quite easy to determine, if risk metrics < defined risk IAM, funds flow to SB, otherwise burn. I think there should be hard minimum(s) on the risk metrics. For example, if CET1 Ratio is <2%, all funds flow to SB. If CET1 Ratio >3%, all excess funds are burned. When the ratio falls in the middle, the SB/burn ratio could adjust linearly until the min/max are hit. These values are purely for illustrative purposes.

Would also like to see how risk is calculating the recommended buffer/values so the community can understand the inputs and pros/cons. I’m not opposed to burning a small % of MKR whenever SB > 0 as well just so the burner is always on and there is no technical atrophy for flaps.

@williamr mentioned the below in the recent signal request thread which I wanted to provide visibility to given the relevancy in this discussion.

Maybe a first step is to maintain clear and transparent documentation on risk weights for each single asset in Maker. Then a second step is to come up with a regulatory capital calculation first (standardised approach), before going on doing our own economic capital calculation.

`

2 Likes

Both @Eumenes and @Aes raised important points. Only two additional ones:

  1. My bias would place maker on a more conservative CET1 Ratio before linear burning (> 5%) to account for higher market/credit risk of maker relative to ADIs (i.e. commercial banking)
  2. The calculations should allow for embedding forward-looking (1yr) assessed provisions on each rwa asset due to estimated credit risk. The estimated provision $ should be provided by RWA CUs.
1 Like

There is absolutely no need to keep raising the surplus buffer continuously. Safety lies in the liquidation mechanism, not in building up buffers. You will never ever be able to buffer when Maker starts to take on huge piles of Treasury Notes and similar debt instruments as the amounts of DAI that can be printed will be enormous but the yield is very low. If you insist on a 2%-ish buffer you will only end up never burning.

8 Likes

It kind of sounds like you are arguing for infinite leverage?

2 Likes

It sounds like we need a more robust discussion of the underlying risk and risk metrics as there doesnt appear to be a common understanding of how to measure the risks

3 Likes

sorry for the delay, had no time this week…

hm no - as long as the Surplus Buffer is not filled, we won’t have any burning. All income will just reside in the System Surplus. With higher SFs the incoming rate will just be higher (assuming same amount of DAI minted).

The desiredBufferPercentage is just a part of the formula to calculate on how high the Surplus Buffer should be, but the growth rate is going to limit the increase of the Surplus Buffer over time.

So if we

  • have the Surplus Buffer filled
  • the income is higher than the expenses
  • the increase of the System Surplus is limited by the Growth Rate
  • the difference between income and expenses will be burned deducting the increase by the Growth Rate over time

does that make sense?

2 Likes

That’s going to be pretty hard onchain :wink:

I feel this can be done by setting appropriate desiredBufferPercentage?

Absolutely.

We never said embedding credit risk into maker was going to be easy :wink: . But we need to start somewhere… We can start those calcs offchain until we’re comfortable enough for an onchain param.

does that capture your idea?

1 Like

yeah, maybe my approach of thinking how we can get this into solidity is too strict here. I want to draft something that we can code as a IAM - the parameters would be under governance controll and should be able to reflect those onchain calculation results.

1 Like