[preMIP] IAM for Surplus Buffer

After spending some time reading through different proposals, it’s apparent that burning is low on the priority of those who are most involved with governance here. I believe in order to keep mkr attractive and fair to investors, a promise needs to be made to first burn, and then use the remaining profits for surplus buffer increases for risk management and expenses.

The problem with simply increasing the SB at some rate is that while the stated intention is to burn some percentage of profits, in actuality the SB increase is prioritized and the SB cap is increased even when what’s in the buffer gets reduced due to expenses or other events which result in a loss. For this reason, I would propose that the growth of the SB cap be paused whenever the content of the SB drops below 1 week worth of revenue from the cap. This would guarantee that you are in some state close to burning whenever an increase occurs. If this is difficult, it can also be implemented less precisely by only allowing growth when a certain % of the buffer is full.

Alternatively, you can set aside some % of revenues for the purpose of burning. This doesn’t have to be a huge amount but any guaranteed amount would provide peace of mind for investors who simply want some return on investment. I understand that the surplus buffer has its value and importance but if all funds flow toward it for sustained amounts of time, the picture is one of insiders hoarding profits for themselves, especially if expenses increase proportionally to profits in the name of growth.

2 Likes

Hi @Traster_Tray !

this preMIP discussion is about to setup an IAM on top of the existing mechanics (Surplus Buffer to prevent any income to the System Surplus to get burned immediately). I see where you are coming from, but I am afraid the changes you want to make are more on a fundamental level and not achievable by a IAM for the Surplus Buffer.

so this can be achieved with this IAM (in its current state): even if we set the desiredBufferPercentage to a level reasonable from a risk perspective we could have a riskAppetite far below 1 so that the Target Surplus Buffer is not x10 compared to the current Surplus Buffer. If we then set the Growth Rate in a way that the projected increase of the Surplus Buffer over time is lower than the projected income, we will burn a (high, low - depending on the parameters) fraction of the income.

HTH

1 Like

IMO all of these percentages really miss the whole point of the SB and are at best a imperfect heuristic for setting the stability buffer.

I think what really needs to be done here is that you should be spending more to further build out the VaR models produced by the risk team in the past to determine this value.

See: Governance and Risk Meeting: Ep. 86 - YouTube

At the end of the day the real risk associated with most of these collateral types comes down to them being relatively illiquid and a large sell off by the protocol could possibly create large disturbances in the price of most assets resulting in losses that are quite large.

The thing about that is that it isn’t a linear function so no % based solution really gives you coverage as your risk grows exponentially as you take on more collateral.

IMO until you sit down and take the time to re-evauate what your VaR is your best option is to keep burning MKR in an attempt to store your excess cash reserves until a future date.

Once you have a robust solution for determining VaR then you could potentially consider some automatic mechanism for adjusting the SB but not before.

2 Likes

Hi @Andy_McCall

People have been complaining about the governance overhead of maintaining the Surplus Buffer for a while. I took the initiative to propose a IAM for that, so we can agree on some more meta parameter instead.

Do I? I don’t think so. I offered an initial proposal, and I never said it is perfect.

To quote Voltaire here: Don’t let the perfect be the enemy of the good.

But if a shitty approach triggers other to get angry and come up with a better solution - that’s exactly what I want to achieve.

We all would benefit from a proposal based on VaR as an alternative. Maybe @Risk-Core-Unit chimes in here at some point es well? My assumption has been so far that something like desiredBufferPercentage would be sufficient from a risk perspective.

If not, great. Let’s iterate. But doing nothing (and especially not touch the SB until we find the perfect solution) is not an option.

One suggestion. The Surplus Buffer should not be raised if there were no burns over the past week.

Due to CU expenses draining the SB, or lower weekly profits, it’s possible for no burning to happen while the SB to keep getting raised.

This will ensure the SB raises gets paused so that you can get a trickle of burns in.

I like this idea, also keeps the keeper ecosystem alive. But don’t think this could be done through onchain code unless the flapper keeps a field of “last block of burn”…

@ultraschuppi There’s a Flap Auction Counter (each auction is numbered). kicks

There might be another way to do it.

I’m just not so convinced that the governance overhead is actually a problem and I fear that you are rushing a solution here for a non issue.

Sure there was a lot of debate over the past week or two in the SB signal request but it’s one of the biggest issues for the DAO and should be thought through extensively

What I would be worried about here are issues of moral hazard where users assume you’re covered by some automatic solution that is in place, but in fact your coverage is quite limited bc automatic solution is inadequate for the problem space.

4 Likes

Looking back to the period from June-Aug, I think profitability will have to be an input in this discussion. What was seen in that period was that the buffer wasn’t getting filled because every time it got close expenses got pulled. There isn’t much point in setting a limit that will take years to fill.

This also speaks to the limitations of the SB as a tool of risk management. It is contingent on the protocol generating a profit quickly enough to match the necessary levels of surpluss.To me it makes more sense to manage that risk through more conservative debt ceilings.

Oh that is definitely true, but a hard sell to this group. In the past before everything was put on an IAM risk would set hard ceilings for each collateral, but anytime those ceilings were hit people would be on the forums petitioning for ceilings to be raised so you end up in a sort of catch 22. Where risk says “this is a tolerable level of risk” and governance says “lets take more risk.”

Ultimately i don’t see the “let’s take more risk” argument as necessarily a bad thing. People are just trying to maximize profits I think, but ultimately risk’s hands get a little tied by it all.