Technical MIPXX: Throttled Surplus Buffer [PRE-MIP DISCUSSION]

Title: Throttled Surplus Buffer
Author(s): Matthew V Rabinowitz (@mrabino1)
Type: Technical
Status: Pre-MIP Discussion
Date Proposed: 2020-12-09
Date Ratified: Pending
Dependencies: N/A
Replaces: n/a
License: n/a


Sentence Summary

This proposal defines a MakerDAO Module implementation to throttle the Surplus Buffer with a known target over a period of time (either up or down) with a set frequency for changes.

Paragraph Summary

As the community continues to tweak the system, one attribute that is sometimes modified is the Surplus Buffer. DAI once over the Surplus Buffer the triggers the FLAP auction to go acquire MKR from the market. One can imagine that if the Surplus Buffer is set to 100MM DAI (and is full) that if governance then subsequently shifts to a materially lower Surplus Buffer of 2MM DAI, it would “slam” the FLAP auction causing a surge of MKR buying and thus huge inefficiencies with price. As it is administratively annoying to reduce the Surplus Buffer manually by governance for a set amount each week (e.g. 2MM decrease per week) as it would require the same vote over and over, this MIP proposes to modify the Surplus Buffer in an automated linear manner using three fundamental variables.

  • Time to reach the target

  • The target itself

  • Frequency of the reduction

From there the Surplus Buffer would then be modified (up or down) over time and with the frequency determined by governance. The frequency if set to zero would throttle the buffer down per block or could be set at a higher number if governance wants to have a more edgy reduction.

The above scenario is magnified as the system gets larger.

Component Summary

MIPXXc1: Time where the time to reach the target is defined.

MIPXXc2: Target where the Surplus Buffer will ultimately arrive at the time above.

MIPXXc3: Frequency the pace at which the above changes will be implemented (e.g. per block or per hour, etc)


See paragraph summary above.


MIPXXcX: Smart Contract Components

See component summary above

MIPXXcX: Proposed Code (WIP)


MIPXXcX: Test Cases

  • Increase the surplus buffer with zero time with Y frequency

  • Increase the surplus buffer with X days time with Y frequency

  • Decrease the surplus buffer with zero time with Y frequency

  • Decrease the surplus buffer with X days time with Y frequency

MIPXXcX: Auditor Information and Report

The code has not been audited (as it has yet to be written).

Prior to any executive vote, the smart contracts domain team shall determine if an audit and bug bounty program is necessary.


Super awesome Matt! Happy to see more community members shaping the future of the DAO.

Looking forward to a presentation of the Throttled SB in 2021!


seems that we can use @hexonaut PSM Lerp module to set a new value progressively.
The code is there and will be audited as far as I understand.

pending audit and audit payment -
thinking the timestamp might need to be changed for blocknumber and tick allowlisted.
but audit will tell

Edit : Pending license right too :wink:


Yes @alexis is correct. This is exactly what I made lerp for - linear interpolation on any administrative variable in Maker. The Quantstamp team will be looking over this contract as part of the PSM audit, so it is free to be used later for purposes such as this.



Is it possible to raise the surplus buffer with X target time frame and still maintain x% of stability fee income going to MKR burns? I think there are advantages of being able to raise the buffer without turning off the FLAP auctions altogether.

though I wasnt thinking to have it be a percentage of stability fee income, that would be a cool further abstraction…

in general we should be able to slowly scale up… and slowly scale down… so if we are burning MKR… this would basically slow down the burning while simultaneously increasing the buffer… on the reverse, it would temporarily increase the burning instead of a slam …

You can change the time frame to adjust but you can’t adjust based on %.

I believe it can be done by having a buffer on the other side plugged in to the reg. Aka:
if x% (or 550dols )
put inside the buffer until someone takes it at x%

Thinking, we probably need another MIPXX for that.


1 Like

The core purpose to MIP I am proposing would be to keep the economics of MKR buying efficient (to help inhibit the otherwise community caused tsunami of MKR buying and artificially driving the price up).

I think that if we start to mix other policy (accounting / monetary), then that should be its own MIP / proposal. My $0.02 … Thoughts?

1 Like

I think there are separated problems.

Throttled surplus buffer. Need to be in front of the process
And seems to be part of the spell as the module is there.

Where MKR buying efficientcy should be treated differently. Need to be plugged at the end of the workflow.

1 Like