[Informal Discussion] Automatic surplus buffer increase cadence

Yes, you are right, risk team has in the past given guidance that the surplus buffer should be in a range of 2-4% of debt issued from volatile collateral in order to absorb losses. With 586MM Dai issued from volatile collateral that means our buffer should be between 11.7 and 23.4 million Dai.

Right now our coverage is 0.68%. I suggest we bundle an increase of $250k in the stability buffer each week. In that way we will reach the 2% coverage level in 31 weeks, and roughly $30k of protocol income would still be used for buying MKR. The proportion of of income used to burn MKR would increase as more loans are issued and more stability fee income is collected.

Alternately, as you suggested, we can look back at the total fees collected in the previous week, and increase the stability buffer as a percentage of that.

We can continue this until we reach the 2% coverage level, at which point we can decide to anchor the surplus buffer to 2% of volatile Dai supply or do something else.

1 Like

Agree @zenithlight. I do think though that we need a mechanism where percentage of fees are distributed to accomplish this, rather than constantly having votes to enable and disable MKR burn to increase Surplus.

And when risk is growing because of larger Dai supply, the fixed weight assigned to Surplus increases nominal Dai added to it because fees are nominally larger. When risk increases due to some structural risk changes (unrelated to higher Dai supply, related more to collateral risk), you just increased weight for surplus.


Thanks Primoz. My opinion is that the level of the surplus buffer should be equal to SURPLUS_FACTOR (systemic risk level) * VOLATILE_DAI_SUPPLY. Anything in excess of that should be used to burn MKR. The cadence can be used to set the level of surplus, while a system like FlapperDistributor can control how that level gets filled.

Since FlapperDistributor needs smart contract work, and (IMO) we have to urgently increase surplus, a flat cadence can allow us to begin to consistently increase surplus in a palatable way, since it is automatic and MKR still consistently gets burned.

I think the ideal end scenario is an automatic cadence that sets the surplus level by reading VOLATILE_DAI_SUPPLY at the smart contract level, so that governance only needs to vote on SURPLUS_FACTOR. It can be used in combination with FlapperDistributor to fill the buffer up.

1 Like

I an in favour of this idea at aiming to a 2-4% surplus buffer (or even more). Sound good and safe!

However it would really be a shame to have 20millions (i.e., 2-4%) sitting there just in case something goes worng, right? It would be better to invest (in a way we consider VERY VERY safe) the surplus buffer money.

One interesting example is, e.g., to LP the DAI-MKR pair on Uniswap.

Another (perhaps easier) example is just to place the DAI of the surplus in a yEarn Vault (i.e., getting yDAI).

Actually you can’t invest the surplus buffer money, because there is no money. As described in my accounting post, the surplus buffer is a liability not an asset.

I can see 2 things that are possible to do with a surplus buffer:

  • switching the liability type from equity to issued DAI, i.e. giving DAI to someone. Most likely for something that increase the immaterial value of Maker (marketing, domain teams, …).
  • Issuing DAI to buy an asset then destroying the asset (which decrease the equity). That what is done when buying and burning MKR.

There is no way that buying an asset (USDC, ETH, a house, whatever) can decrease the surplus buffer (at least initially, ETH price can decrease just after). If you buy a risky asset, you increase risk so you need a bigger surplus buffer.

That’s why I’m a bit stubborn the the need of accounting and balance sheets. I know it’s not easy. But if we don’t frame the problem correctly, we can’t solve it.


You are 100% right. In fact I was aware of your post, but didn’t mention those complications just for the sake of passing the ‘sense’ of my proposal.

But you are right, we must more and more adopt the right terminology or it will cost us time and resources.

Thanks @SebVentures

1 Like

I have been against raising the SB for quite some while, but i do surrender now - there is really no reason to not have this automatically adjusted depending on the amount of DAI issued by us.

But: can’t we just have this as part of the IAM? Is there any reason why this needs to be bundled into an exec? what about a function that is callable by everyone (maybe every 12h or so…) that sets the SB just as a percentage of the DAI in circulation?

1 Like

My original concern was that if we set the SB value directly to 12M dai, that it will be almost 1 year of no MKR burning before the SB is filled, which many MKR holders might disagree with.

But I think a modified version of the DC IAM is a good way to do this. line can be calculated based on a percentage of issued Dai and periodic MKR burn will still be achieved as top and ttl slowly increase SB towards line.


Now we’re cooking with fire. Come up with a model, this one is probably easy, and then we make an MIP and build it into an IAM. 2021 should have us thinking about ways we can lean on automation to scale governance. This will reduce load on all the other domain teams and governance in the long run, allowing us to focus on new features.


Yes, exactly this.

1 Like

Really good idea IMO and would have my full support. Doing it with an IAM just makes sense. The main question would be at what rate do you move the line up? I’m thinking it should be based around the amount of DAI SFs generated on a daily basis? Like each time the line is bumped it moves up 2 weeks worth of daily SFs generated? That way it’s not something that would need to be called constantly like we’re seeing with ETH B and if we need the income for something else we know the buffer is just a few weeks away from being full once we divert it back.

Or should we be basing the line on the total amount of DAI in circulation (which was my original impulse) since that roughly represents the risk to the system?

what about something like this:

variables under governance:
N - percentage of total_dai that should be the target for the SB
D - min time in days/hours between adjust-calls
M - maximum shift for increasing/decreasing in adjust-calls in relation to previous SB: 1.00 max double, 0.1 maximum of 10%...

function adjustSurplusBuffer(){
  revert if D not met yet
  desiredSB = total_dai * N
  if ( Math.abs(currentSB - desiredSB) < (currentSB * M)) {
    currentSB = desiredSB
  } else if (desiredSB > currentSB) {
    currentSB *= (1+M)
  } else {
    currentSB /= (1+M)

pretty bad with pseudocode right now, looking forward to get some days off :wink:

1 Like

I think the best strategy is to try to burn as much MKR as possible to increase the MKR price. As long as the MKR MCap is so low compared to DAI MCap - the system is in danger. I think at least 30% of MKR supply must be burned (it will take years at current speed) - we saw that burning a few thousand MKR does not affect the price.

Yes and no, IMO. We want to incentivize MRK holders to be in this for the long run, which certainly does mean executing the buy/burn. But I don’t think looking at the market caps and trying to put short term support on MKR is effective (btw, pretty difficult to increase total marketcap when you’re burning it). Also worth noting that if our surplus buffer isn’t large enough to fend off an attack/mistake MRK value essentially goes to 0.

1 Like

This, and, we can increase stability feels collected to burn more MKR if we have the risk buffer to comfortably onboard more collaterals.

We can start by proposing to push the buffer to 10M DAI. That’s 4 months at the current fees. Then we will have the keg and an operational fund to seed and the ability to fine-tune how much should go to MKR burn and how much should go in reserve (reality is a bit more complex).

What is needed for MKR is to increase the revenues, have great governance, and a real structure.

Fine-tuning the surplus buffer increase is like arguing on the color of your logo when your competitor is Elon Musk.


Perhaps this is a good way to move forward

We would still keep the burning to certain extent and it will enable the possibility to fund domain teams and other initiatives if governance decides to.


Wanted to second this. I’ve been looking a bit lately at @Vishesh collateral risk model and have been using it to try and determine the VaR of the whole portfolio. From what i am seeing the DAO needs to set aside something like the next 4 years of revenue (at current levels) just to hedge against the jump risks of it’s loan portfolio. Needless to say i doubt that something people would find palatable.

That being the case, the only path forward I really see is to raise revenue.

I also agree with the sentiment that optimizing the stability buffer might be a bit of “bike shed” idea. Like i said, what i think the DAO needs to be focusing on atm is how it can get cash flows up and preferably how it can do it without taking on more loan exposure.

Raising SFs spreads seems like the obvious choice, but there are likely other revenue opportunities.I wish i could be more helpful on what those might be. I know oracle usage fees have been talked about in the past. Potentially strategic fund investments might also be an option.

I guess i just want to say that i think we need to be mindful about how the portfolios risk exposure is trending, but i don’t think the DAO will ever be able to offset those risks via the stability buffer until the protocol’s current cash intake is in a much better state.


While I still believe it makes sense to think about a long-term solution to this problem I also think you are right that we should not wait for it, so I started a Signal for a short-term solution

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.