[Signal Request] Increasing the Surplus Buffer (2021-11)

I recognize that as token holders, the community may be a little biased toward the optimistic side of things but I also think valuation is only arbitrary to a certain extent. The broader crypto market is difficult to predict and I’m sure many would just as much say this bull cycle has much more room to run. But based on how mkr has performed relative to the market recently and fundamental financial metrics, I imagine most would say it’s at least fairly valued even when adjusted for risk. I also imagine there’s a point where the majority would say the price is more than fairly valued. Perhaps you can automatically slow burning and increase SB more quickly when at or near all time/52 week highs (even if the highs are justifiable by growth).

Your point about reducing the surplus buffer in market downturns is a good one if executed well. However, there’s an element of trust required with the surplus buffer. Since expenses are taken from it, there will always be a temptation to use it for more or continued spending rather than burns even when good opportunities arrive. If you can maintain profitability during downturns, the decision is easier but that might mean reducing expenses which is difficult and contentious.

Please provide your calculation of expected losses. :face_with_hand_over_mouth:

1 Like


It would be difficult to overemphasize the power that burning MKR has to the finance world outside of crypto in my view. When I explain the MKR/DAI structure to a corporate-finance-savvy-but-crypto-newbie colleague, unanimously one of the moments in the conversation in which their eyes open wider in wonder is when I explain that after a certain amount of profit is generated that profit in the DAI stablecoin is automatically used to buy back MKR and then that MKR is burned. A share buyback, a tool that as someone else said here companies as large as $AAPL use successfully to give value back to stock/stake holders.


The perception in the stock market when a company buys back it’s own shares is that the company can no longer innovate and has no superior ways to invest the capital internally, so they return capital to investors.

If you look at price history of MKR, you can see that burning has had no to little impact on the token price. It really only starts to have an impact when annual cash flow is > 5% of the market cap which seems to be a floor value for the MKR token. The faster our cash flow grows and the higher it gets, the more MKR tokens we can burn. When I think about allocating capital, I strongly believe investing more in engineering and real world assets will significantly outperform buying back and burning MKR at today’s prices.


Agree with important nuances. When a company is making money that it does not have the present opportunity to use that profit in a way that will give the shareholder a healthy return, it is the smart call to distribute it to the shareholder as either a dividend or share buyback, like $AAPL. As you read this and I said “in 3 seconds tell me what we can put 60 MM DAI into use today that will likely bring in a healthy return” what would that be? If I was answering I would shrug my shoulders.
Marketing and engineering budgets certainly could be bolstered but would be just throwing DAI away at that level, and we don’t need it to expand DAI use and lending. Which goes to the other nuance - and a beauty of the protocol – that new opportunities do not require a bunch of cash/DAI sitting around but will be created upon doing the secured loan, unlike a bank or corporation.


As a small MKR holder, I am not at all opposed to re-investing earnings in the protocol, but I would like to see some burning. I would like to see smaller, incremental raises of the SB instead of just disabling burning for six months at a time (which is essentially what happened with the last raise, even though it was supposed to burn 25%).


In general, it is hard to know which is better - burn or reinvest in the protocol.

I’d like to see the SB be some fixed percentage of non-stablecoin DAI. Whenever we’re above that percentage, we use the excess to burn. This also removes the governance headache of constantly deciding how much to raise it by.

Just a note that this Signal Request ends on 2021-11-19T14:00:00Z

As things stand multiple options are above the required 50% threshold for inclusion in an on-chain poll.

If this remains the case at the end of the Signal Request, we will be using Instant-runoff voting (IRV) for the on-chain poll.

Please feel free to take this into account when selecting what options you are voting for/have voted for, especially if you are in favour of multiple options.


A further reminder about this poll: multiple options for the surplus buffer size are above 50% when abstentions are discounted so would proceed to IRV voting on chain.

However, none of the lerp options are above 50%. If you prefer the option of some lerp over no lerp please consider voting for multiple options to ensure that a lerp option will be included on-chain.

@Patrick_J Could you elaborate a little on your last post?

The way I understand it, if nothing changes with the votes, the following will happen:

  1. There will be a instant runoff voting between some of the different surplus buffer increase alternatives, eventually landing on one of the proposed values.
  2. Neither of “increase the surplus buffer by 0.67/0.33/1” alternatives is going to make it into the online poll, effectively enacting the “set target level directly - no burning” alternative without going on a on-chain poll.

Is my interpretation correct?

That would be… Weird at least. Would make more sense to have all the lerp options in IRV (a lot of options…)

1 Like

So any option with more than 50% support (once abstentions are removed) will go forward to an onchain poll. If more than one option that represents a change from the status quo gets 50% or more support then the vote will be an IRV. Raising the Surplus buffer is a change to the status quo, so it would need to go through the weekly polls process if it were to be enacted. (sorry if i’m stealing your thunder @Patrick_J :wink: )

1 Like

Edit: @prose11 definitely stole my thunder here

Certainly. I’m afraid this explanation will end up involving some minutiae of the Governance process so if you have any follow-up questions feel free to ask.

First, let me start by pointing out that since that post was made there has been a redistribution of votes and the following 2 options are now above the 50% threshold for inclusion in the on-chain poll:

  • Increase Surplus Buffer by 0.67 MM per week
  • Increase Surplus Buffer by 1 MM per week

A crucial aspect of the Signal Request process is that not all of the options offered to community members for voting in the forum will make it into the on-chain vote. Conventionally, we have used a cut-off of 50% of non-abstain votes to decide if an option is included in an on-chain vote or not. Remember that people can vote for more than one option so it is possible for more than one option to attract the votes of more than 50% of participants. In this instance, we have the ability to submit on-chain polls using instant-runoff voting rather than our usual plurality voting (FPTP) method.

Of course, we need to know what will happen if no options cross the 50% threshold. In that instance, we would consider the Signal Request to be in favour of the status quo.

Once it was realised today that none of the options in this poll in favour of slow increases to the Surplus Buffer (lerp) had above 50% of non-abstain votes we realised there might be a problem with this particular Signal Request. This is because it is the position of GovAlpha that the status quo for Surplus Buffer increases is to increase directly to the new Surplus Buffer. Lerping the Surplus Buffer is an active decision that Maker Governance must make rather than a default assumption.

So in essence, this Signal is asking several questions:

  1. Should we increase the Surplus Buffer?
  2. What size do we want the Surplus Buffer to be?

The default position here is “no, we should not increase the Surplus Buffer”, so if no options passed 50% the Signal would not proceed to on-chain, currently 2 options in favour of increasing the Surplus Buffer have above 50% of non-abstain votes so would proceed to an on-chain vote.

  1. Should we lerp the Surplus Buffer increase?
  2. What rate should we lerp the Surplus Buffer at?

The implication of this question is that it is not automatic that the Surplus Buffer increase is lerped.

Clearly, in this particular Signal Request, there are more people in favour of lerping the Surplus Buffer than not lerping it. However, there was not a consensus on what this rate should be. We realised that this may result in an outcome that had actually received the fewest votes (no burn/lerp) being the option that proceeded to an on-chain vote as this was considered the status quo option. If the poll was to end and an on-chain poll proceed without a lerp option then Governance participants may rightly be confused or frustrated. Consequently, we decided to post both on the Forum and on Discord to highlight this discrepancy to voters.

As things currently stand in this Signal Request an on-chain poll will likely be an instant-runoff vote with 6 options:

  1. Abstain
  2. Increase Surplus Buffer to 90 million, with a gradual increase of 0.67 million per week
  3. Increase Surplus Buffer to 130 million, with a gradual increase of 0.67 million per week
  4. Increase Surplus Buffer to 90 million, with a gradual increase of 1 million per week
  5. Increase Surplus Buffer to 130 million, with a gradual increase of 1 million per week
  6. No change to Surplus Buffer

For what it’s worth, from a personal perspective I am not sure that the potential for the lowest scoring option to proceed on-chain is a desirable outcome for a Signal Request and I will be bringing this up at the weekly GovAlpha CU meeting next Monday as something we might need to provide clarity on moving forwards.


First of all @Patrick_J, thank you for a very informative post.

For what it’s worth, from a personal perspective I am not sure that the potential for the lowest scoring option to proceed on-chain is a desirable outcome for a Signal Request and I will be bringing this up at the weekly GovAlpha CU meeting next Monday as something we might need to provide clarity on moving forwards.

This is what struck me as odd and I think should be investigated further. I think the situation could have been avoided if the signal request had been broken down into the four questions in your post.
I think the problem originates in having several options that are essentially degrees of a preferred solution. In most cases you’d expect to have opinions fall along a spectrum with some overlap, depending on the overlap you might very well end up in a situation where there is consensus for a direction but fragmentation in magnitude. In such a case I think it makes sense to do an instant run-off on the magnitude.

Another aspect of this particular signal request is that the second question is dependent on the first. It doesn’t make sense to restrict the growth of the surplus buffer if you’re against raising it in the first place. This can lead to a portion of voters voting “abstain” in the second poll because they didn’t find an option for “Increase Surplus Buffer by 0 per week”.

Your choice in the second poll can also change if the assumption is that there is going to be an increase vs. there isn’t going to be one. It’s a secondary kind of vote.

To exemplify: My initial stance is that there isn’t going to be an increase so I abstain the second vote. However, upon learning that there is going to be an increase, I might prefer the surplus buffer to either be filled quickly or more gradually. A second example. I initially prefer an increase of 130MM, but on learning that there might not be an increase without consensus I might prefer 30M over nothing even though I think that is way too low.

In both cases I think it makes sense to separate the principle from the magnitude. First do a vote whether to increase or not, and then do a vote on how much under the condition that there is going to be an increase. Secondly do a vote on whether there shall be a gradual increase in the surplus buffer or not and then do a vote on how gradual that change should be under the condition that it is going to be gradual. Both the dependent votes would naturally lend themselves to instant run-off votes.


Thanks everybody for participating in this very vivid Signal Request - the Poll is now closed.

I am really grateful for all your comments and looking at the amount of voters this Signal Request is by far the most active one I have initiated so far- thanks a lot!

I expect an onchain poll happening about this on 2021-11-21T23:00:00Z - I am really happy not to do the PR for this one - thanks in advance to @Patrick_J :slight_smile:


Thanks schuppi

Just wanted to confirm the poll outcomes and clarify what the on-chain vote will look like.

Results are as follows for the first poll:

To which level shall we set the Surplus Buffer?

There were 82 unique voters, of whom 12 were abstentions.

Option Non-Abstain Votes Percentage Outcome
90 MM (+30 MM) 51 72.9% Move on-chain
130 MM (+70 MM) 40 57.1% Move on-chain
60 MM (no change) 24 34.3% Rejected
170 MM (+110 MM) 19 27.1% Rejected
210 MM (+150 MM) 17 24.3% Rejected

Results were as follows for the second poll:

Shall we increase the Surplus Buffer slowly so we keep burning a fraction of the profits?

There were 76 unique voters, of whom 17 were abstentions.

Option Non-Abstain Votes Percentage
Increase Surplus Buffer by 0.67 MM per week 32 54.2% Move on-chain
Increase Surplus Buffer by 1 MM per week 30 50.8% Move on-chain
Increase Surplus Buffer by 0.33 MM per week 28 47.5% Rejected
Set target level directly - no burning 19 32.2% Rejected

As a result GovAlpha will be submitting an on-chain governance poll on Monday with the following options:

  • Abstain
  • Increase Surplus Buffer to 90 million, with a gradual increase of 0.67 million per week
  • Increase Surplus Buffer to 130 million, with a gradual increase of 0.67 million per week
  • Increase Surplus Buffer to 90 million, with a gradual increase of 1 million per week
  • Increase Surplus Buffer to 130 million, with a gradual increase of 1 million per week
  • No change to Surplus Buffer

The poll will take the form of an instant-runoff vote. Assuming a positive outcome, the winning option will be included in the following executive vote.

Thank you to everyone for voting and participating in the discussions surrounding this poll.

@JustinCase, please don’t think I’m ignoring your post, I think it will be better to address the issues you raise in a separate thread from this Signal Request as they deserve further discussion. I hope to post some feedback following our CU meeting next Monday and will ping you in the relevant thread.


The poll is over and the discussion has been thorough, but I want to throw in my two cents.

As investors in MakerDAO, the two major categories of risk we must consider are:

  1. Risk of permanent loss of capital
  2. Risk of lower than expected returns on investment.

MakerDAO’s ultimate long term success is extremely dependent on preserving the reputation of the Dai and it’s peg.

Keeping a strong Supply Buffer will allow us to avoid permanent loss of capital by preventing MKR being minted at the worst possible time, and will also safeguard the reputation Maker governance, which is the widest moat Maker can have.

However, burning MKR when it is undervalued will greatly mitigate the risk of lower than expected returns.

I propose the following heuristic:

Rule #1: As long as the Supply Buffer is below the risk mitigation sweet spot, some revenue must be directed towards growing the supply buffer.

Rule #2: As long as MKR is undervalued, some revenue must be used to burn MKR.

I conjecture that a 90/10 or 10/90 split in any case will perform better over the long run than 0/100 or 100/0.

Calibrating the split, the buffer sweet-spot and the valuation of MKR is up to long term governance, but as long as the two rules are followed, I will feel very happy owning Maker for the long run.


The on-chain poll for this Signal Request has now ended. The vote can be seen here.

The winning option was “Increase to 90 million by 1 million per week” and this change will be included in tomorrow’s executive vote.

Thank you to everyone for participating in this Signal Request.


Closing the loop here, the executive spell containing these changes was executed on Nov. 29th. The surplus buffer is on its way up to 90M at an increase rate of 1M DAI per week.


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