Pre-MIP discussion: Burner 2.0 - feel the burn


The existing burner (from now on called Burner 1.0) buys MKR and burns it, removing MKR from the market by nibbling. This slowly but surely decreases supply and so increases the value of the remaining MKR in the same manner a share buyback functions for a publicly listed company. The most widely voiced criticism is the inefficiency of the process, MKR is bought and burned when it is expensive.

Burner 2.0 seeks to improve on Burner 1.0 by introducing the features of event triggering, event branches, randomness, and game theory. The goals are:

  1. In general, but not always - burn MKR when it is cheap, not expensive. So more burn.
  2. Increase MKR price upside by fewer, larger, and more unpredictable burns.
  3. Decrease MKR price downside by a burner system designed to probabilistically kick in more often when the price is deemed low.
  4. Introduce randomness for increased fear-of-missing-out (FOMO).
  5. Allow for the potential partial gaming of a burn event, increasing interest.
  6. Introduce uncertainty possibly resulting in drama at Burn events for increased interest in the MKR token.
  7. Maximize the fear, uncertainty, and doubt (FUD) experienced when holders sell MKR. It is not a burn until weak hands cry tears of regret.
  8. Burn events are semi-randomized, no direct attempt is made to try to time markets.
  9. The burn event has a secondary function as marketing for the MKR token.

Triggering a Burner 2.0 event - introduction of uncertainty

In Burner 1.0 (what we have now) DAI accumulates until a certain threshold is reached, triggering a burn event in the form of a Flap auction.

In Burner 2.0 the chance of a burn event is not determined by the amount of DAI in the buffer, it is determined by a function operating using 2 parameters and randomness, eventually triggering a burn event. DAI accumulates until a burn event is triggered.

The Maker community (or rather the Rates Group) will set the parameters for the two-step changes for the burn event function. Alternatively, a 6-months trailing high-low can be used, whatever is deemed the most practical. It is important to note that when the price of MKR crosses these settings it will not automatically trigger a burn event, only change the likelihood of it happening. The actual event triggering is done by a probabilistic function triggering about 3-4 times per year on average, no more.

Uncertainty is used here to prevent gaming and increase stress. Holders of MKR looking to sell can never rule out a burn event, no matter how high the price of MKR is. The same principle applies during periods of low MKR price, the chance of a burn is much higher, providing a disincentive to selling. Do note that holders cannot count on the event happening and so are deterred from activities that increase system risk such as leveraging MKR tokens. Please note that no direct attempt is ever made to time the market.

The Burner 2.0 event - multi branch event tree

After the probabilistic function has initiated a burn event, the burn event itself can take multiple forms, so-called event branches.

Market notified: could be a tweet, reddit message, an onchain message or something else.

A brief explanation of the event tree. The market may or may not be notified of an MKR burn event. In the case a notice is given the actual point (block) when this will happen is not specified, merely that it will happen in a certain interval. The relevant interval may be varied. Do note that a minimum amount has to be bought, as the Maker community otherwise could be accused of providing the market with false information.

The Burner 2.0 event - game theoretical discussion

A brief game-theoretical and psychological discussion of the burn event branches.

Branch 1 - initiate burn without notification. The market is not notified of an MKR burn event, this is similar to the Burner 1.0 process. The differences are the much larger sums involved and the much higher pace of buy and burn. Depending on the amount of DAI available for the burn and the timing of the burn the result in the markets is anything between a wet noodle and a complete eye-popper. The sheer possibility of this happening increases the opportunity cost of not holding MKR, otherwise referred to as fear-of-missing-out (FOMO), as most investors are unlikely to have sufficient time to buy in. To the market the message is clear: holding MKR is the only way to profit from unannounced burns.

The secondary effect of the branch 1 event is the media effect of a strong burn on a surprised market, also known as a surprise attack or Blitz effect.

Branch 2 - notify market, burn minimum amount. In the case a notice is given the actual point (block) when this will happen is not specified, merely that it will happen in a certain interval. The interval may be varied to allow partial gaming while maximizing degen stress. The market is now subjected to an announced event and may or may not respond. The burn event ends however with just a single, or minuscule amount of, MKR being bought and burned, saving the remaining DAI for the next event. This is a conscious tease and denial tactic, hugely increasing the psychological impact of the burn event with minimal spending of funds. Do note that a small amount must be bought, as the Maker community otherwise could be accused of providing the market with false information. There is of course a limit to the number of times this tactic can be played out before the market seizes to react (aka cry wolf syndrome) therefore the probability for this event is set just a bit lower so the degenerate will know deep down in his greedy soul that statistically he has only himself to blame if he misses out. With the event ending with the available funds nearly intact, the stakes are significantly raised for the next burn event.

The secondary effect of the branch 2 event is the strong meta game where both social and mainstream media can weigh in. This is comparable to the effects of a lottery with no winner where the pot is doubled for next week’s draw, providing free drama.

Additionally, there will likely be increased trading of the MKR token as players positions themselves to take advantage of a price increase and find themselves disappointed and now in a position to sell. The counter-strategy to this are players positioning themselves precisely to take advantage of any branch 2 event selloff.

Branch 3 - notify market, burn full amount. In this case, notice is given and at an undisclosed time inside the disclosed period, all available funds is used to buy and burn MKR. The market will react but will most likely not be surprised. The psychology of the event is predictable and nothing out of the ordinary happens and most information is on the table. Looking at the event tree probabilistically, this is by a tiny margin the most common occurrence, preventing actors from assuming or blaming the community for acting in a manipulative manner. Secondary effects of the branch 3 event are most likely none.

Discussion: What are the possible results in the markets of a burn event? Reference is made to the events taking place on Uniswap in connection with the price of MKR increasing from DAI 2,300 to DAI 4,000 over the span of four days starting April 11, 2021. Over these four days the entire buy-side amounted to roughly DAI 30 million distributed across 3,400 transactions, with Uniswap volume exceeding centralized exchanges. DAI 30 million is roughly one-quarter of what Maker generates in fees, coinciding reasonably well with the proposed 3-4 burn events annually. This means that a Burner 2.0 burn event, without any assistance, can potentially generate 74% increases in the MKR price. The price increases possible when the market does detect and reacts to such an event would quite possibly be dramatic. On the other hand price increases could be non-existent if a major holder decides to dump into the burn. The above April 2021 event did coincide with a major holder offloading MKR 3,100 onto Uniswap. The range of outcomes is in other words wide.

What do you think? Please comment below.

Next steps: unless someone with reasonable dev skills volunteers to pick up on this before the end of June this proposal goes back into the drawer.

Update 14 July: this one is back in the drawer for now.


Still reading it, but if you’re trying to search for an optimal strategy, why not do something like an epsilon-greedy algo instead of pre-set percentages?

Very interesting, in general I like the idea of playing around with how we burn, especially in terms of optimizing its efficiency.

One big obstacle I see however is executing this randomness on chain. It is very hard to get probabilistic outcomes onchain, and randomness still hasn’t been solved. How would we account for so many events in the decision tree requiring probability? Would the gas required to approximate this counteract any increased burn efficiency?

Wow. You put a lot of thought into this! I would personally love to go with a simpler threshold mechanism based on excess reserves and P/E. If we had a MKR/USD oracle and a way to calculate our P/E based on DAI generation to vat we could have a governance adjustable parameter for when to burn MKR. P/E < 20 = burn above SB.


I think it’s important to look them from Keepers’ perspective. The more unpredictable auction takes place, the less competitive it will be and thus burn less


Well the thing is that the proposed mechanism needs randomness to surprise the market. Excess reserves and P/E ratios are visible figures and so will allow investors to time the burn. We do not want that.

Yes. Well, we could have a Random-Oracle linked to offchain sources of randomness I guess.

It would not have to update very often, maybe once per day. But in general you are correct - unless randomness can be provided with an amount of elegance this will go nowhere.

1 Like

Considering PE is now below 8, would be a good time to burn tbh

1 Like

Yes. This is an important consideration. Possibly it would be better to move auctions onto a AAM.

1 Like

Ideally auctions will be moved to Liq 2.0 or similar, or even just have the MKR market bought on a DEX/aggregator. That’s probably the most efficient way to do it and auction bidders are most likely going to be arbitraging anyway.
Presumably that would not be difficult to implement?

“Next steps” added.