A Governance Model for Maker

Continuing on from this thread: Signal Request: Should we replace the weekly DSR Rate governance poll with a DSR Spread governance poll?

The poll end date is almost here and it seems we are mostly in alignment for a switch to a DSR Spread. It has become clear to me since running that last poll that even though most people agree on switching to a DSR Spread, we are not in complete alignment on the governance model in the first place.

I wanted to open this thread to start discussion on the specifics of what should be voted on, how we interpret those votes and how the results of those votes are encoded into system parameters.

See the Jan 2nd governance call for my presentation here: https://youtu.be/dRG1TThjv5c?t=1275
Slides here: https://docs.google.com/presentation/d/10x5Z0111Lt6tOMsqhiZop53QiLLSRxqaQKVvyPY6D-U/edit?usp=sharing

In particular, I want to propose this governance model for after migration:

Since the creation of this presentation, @cyrus has made a good point about allowing vault-type (ETH-A, BAT-A, ETH-B, etc) subsidies / taxes as well for low-volatility assets such as US Treasury Bonds. I think it’s a good idea to have the vault fees be a combination of Risk Premium + Subsidy / Tax.

For example: we want to encourage a subsidy for US Treasury Bonds by keeping the total fees paid by borrowers to always be at most 1% and the Risk Premium for the vault type is 0.1%. Let’s say general market conditions give us a 4% Global SF and we run the DSR Spread at 0% (DSR = Global SF). We can achieve this by setting the vault fee subsidy to be 3.1% so that the total fees paid are 1%. This allows a borrower to gain 2.9% interest via the DSR. In this example the fees are encoded as:

Global SF = 4%
DSR = 4%
US Treasury Bonds Vault Fee = 0.1% - 3.1% (RP - Subsidy Rate) = -3%
US Treasury Bonds Total Fee = 4% - 3% = 1%

A technical note: the dev team has said negative vault fees are currently not possible, but this could be changed in code.

I made this thread as a general idea dump, so we can hone in on the specifics. I definitely do not have all the answers, so please object with better ideas if you have them! :slight_smile:


I’m not sure whether your US Treasury Bond example makes sense, but I’m in agreement with the rest of your presentation. Good idea to express DSR as a proportion of the global fee. We can address negative vault fees later. One step at a time.

1 Like

Watched your presentation. Excellent man!

I agree with pretty much all your proposed. Seems to make sense.


If anyone would like to watch the recording of Sam’s presentation check out the video linked below (time starts at 21:20)


I may start another thread but I have been thinking of an alternate approach to the DSR by simply paying the DSR based on a % of the fees.

Simple example.

If we were to take 50% of ALL of the fees and pay them out to the DSR it would give the following rates based on DSR utilization.

~110M in loans at ~5%/yr generates ~5.5M/yr in fees.

DSR utilization is at 30M which using above numbers would be paying a DSR rate of 9.15%
If the DSR utilization were to increase to 60M this rate would be ~4.57%
If DSR utilization were to drop to 10M the effective DSR rate would be 27.45%

I am not saying the DSR rate needs to be 50% of all fees. It could just as easily be 10,20,30% or even 110%. My point is that I think it would be far better to define the DSR payout as a percentage of fee revenue and to allow the DSR utilization (via users) to determine the DSR rate.

Notice that the community can still adjust the payout percentage of fees and thereby manage sopping up or releasing liquidity but that the markets (i.e. depositors) would be able to choose whether the rates/risk of holding DAI in the DSR is a better choice than alternatives.

The negatives: I don’t know if this kind of change requires a change to the smart contracts or not (biggest negative)
Fluctuating DSR rates may be unattractive to some users and may not be competitive with some fixed return markets.

The positives: A fluctuating rate based on facility usage will probably compete better with the rest of the ecosystem. Defines exactly how much of the Maker revenue will not be used for burning Maker giving MKR holders a better idea of how much revenue via burn they can expect. In the end this kind of model likely will provide an overall BETTER return to depositors than a fixed rate. The system is less susceptible to rate arbitrage. The actual DSR rate as determined by payout % and utilization should give much better data visibility with respect to PEG responses than a fixed rate against changing markets. In effect the above kind of payout approach will do much better at floating properly with market needs and should give a significantly improved data source with respect to what rates are doing against the DAI PEG to the dollar. Conceptually this is also easier to think about from a Maker profit and governance perspective. This approach is also likely to be MORE robust against changing market conditions than the fixed rate approach currently chosen.


I think I am starting to change my mind on this one as well. Setting the DSR to a percentage payout from revenue seems like the more natural fit to the growth/profit lever. DSR Spread could be ask for as a percentage 0%-100% of the Global SF where 0% means all revenue to MKR holders (DSR = 0%) and DSR Spread of 100% means all revenue to the DSR holders (DSR = GSF). I assume in the long run DSR utilization should approach 100%.


Yeah, this sounds like a good idea because it is more generous to DAI holders and MKR holders can still receive a predictable proportion of the fees. Will implementation require changes to the smart contracts?

Most of the revenue comes from vault fees which are set by the executive vote, so we can get this information by governance votes with no change to the smart contracts.

If you want to set this more dynamically (such as take the DSR utilization into account) then yes you will need to modify the smart contracts.

The status quo, where we don’t take DSR utilization into account, could cause MKR holders to discourage DSR usage. I’m not saying that this is actually happening, but it seems like a misaligned incentive. Incentive-wise, MKR holders should want to make DAI holders happy from every angle.

I think there are two things to consider.

  1. Whether in principle we would find consensus in the community on a % of fees going to the DSR and the resulting DSR having in effect a floating rate vs. a fixed one.

  2. The harder question that would have to be asked of the contract developers is whether the smart contracts would need to be altered and how hard that would be. As I am not a smart contract coder I will try to stay out of the way this might be implemented and focus on whether the community thinks it is a good idea. If we can reach concensus that (1) is the preferred DSR model then we can talk about what it would mean from a development perspective.

I much prefer a floating DSR as any constant DSR we pick will always be less than or equal to a DSR = GSF lock. It is not our job to provide a constant savings rate to DAI holders. It is our job to keep the peg in line and running a deficit (in the case where DSR > GSF if DSR is held constant) to maintain a constant DSR is counter-productive to this cause. By this logic we can guarantee that any variable rate will be greater than or equal to a constant rate which is a better value proposition to DAI holders anyways. Why would you turn down a higher savings rate than what can be provided by a constant DSR?


I completely agree hexonaut!

As I said before and I want to re-iterate this I believe such a ‘floating’ rate will provide a better DSR/PEG data source than a fixed DSR that does not reflect or change with changing market conditions. This is a key point I want people to pay attention to.

This approach gives up almost nothing (except maybe somewhat more smart contract development time/costs) and retains everything needed to manage the markets using how much interest is paid to the depositors.

Everyone wins in principle here and I think we get better data to satisfy the scientific governance piece for Makers stated goals. It is my hope that this will also mean LESS frequent changes to this value to maintain the PEG and hence less need for governance votes.