[Informal Discussion] Automatic surplus buffer increase cadence

Hi all,

While the onboarding of USDC collateral has helped lower the price of Dai somewhat, it still remains firmly above the peg. As long as Dai remains above the peg, loan growth should be the number one priority for Maker.

As we onboard more types of decentralized collateral as well as untested collateral types like RWA, we encounter different kinds of risks, and we have to subsidize those risks to some degree to ensure Maker remains the preferred borrowing platform during this crypto growth period.

I propose a surplus buffer increase cadence, which, if passed, will be bundled with each weekly executive vote. A change or halt to the cadence will need to be passed through the signal process as opposed to the status quo where any increase in the buffer must go through the full governance process. The cadence can be anchored to a percentage of Dai in circulation or a flat increase week over week.

This allows us to be prepared for the increase in risk we take on during this rapid growth period as well as prepare us to make large capital spending decisions without the help of the Foundation when we need to.


Yeah, a cadence can be nice with the current limitations. You still get some periodic buying of MKR when the surplus gets capped for a bit.

1 Like

That seems like a reasonable proposal @zenithlight .

As discussed here. The level of surplus buffer we need to have really depend on the risk appetite of the Maker Governance. The rest is just on how to optimise fees generation for a specific size of surplus buffer. But, obviously, it’s not easy to model all the correlation and end up with the perfect surplus buffer size for a given balance sheet and a risk appetite. Should we risk MKR dilution once a year, once a decade?

What about burning MKR with 50% of the fees and using the rest to increase the surplus buffer? Like with increase the SB of 1M every 2M fees.

1 Like

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.