[Discussion] Add on-chain governance metadata

Warning - This is a technical conversation.

Up until recently we have been voting on actual smart contract parameters such as the Stability Fee, but starting with the switch to the DSR Spread vote as well as the more recent Base Rate + Risk Premium split we have started building a layer of abstraction that is beneficial to scaling governance. I expect this trend to continue. For example, I’ve already heard discussion on enforcing a global debt ceiling for all centralized stablecoins.

As we start to abstract away from the actual system parameters, I think it will be helpful to record human-level parameters as on-chain metadata either during the executive or whenever these parameters change (such as in Instant Access Modules). This will give us an on-chain source of truth for the governance parameters MKR holders are thinking of. I see two ways to do this:

Method 1: Add an additional metadata smart contract

I will leave it to the dev team to suss out the details, but I am imagining an additional metadata module being added as a smart contract where you can assign float values to arbitrary strings.

For example)

Let’s say the metadata smart contract has these values:

BASERATE = 0.02 (Base Rate is 2%)
ETH-A-RP = 0.03 (ETH-A Risk Premium is 3%)
BAT-A-RP = 0.05 (BAT-A Risk Premium is 5%)

and a governance vote passes for raising the Base Rate to 3%. We could then add the following lines to the executive vote to update this in the metadata smart contract:


// Set the actual values
JugAbstract(MCD_JUG).file("ETH-A", "duty", whateverActualSystemDuty1);
JugAbstract(MCD_JUG).file("USDC-A", "duty", whateverActualSystemDuty2);
// ...

// Set the meta data
metadataContract.SetValue("BASERATE", 0.03);


  • Flexibility for future structural governance changes as it doesn’t require smart contract adjustments for structural changes.


  • No enforcement mechanism. The numbers are arbitrary and the executive smart contract author could make a mistake.
  • Increased gas cost. Strings are expensive storage.

Method 2: Hook up an intermediate “parameter-translation” module

This would be similar to Method 1, but instead of being arbitrary strings it would be specifically for the fees defined in governance (Risk Premium, Base Rate, etc), and it would actually set the underlying parameters instead of just being a non-enforcing side-module.

This would be doing the calculations that are currently being done by a code-generating script inside a smart contract. Example of how to set the Base Rate to 3%:




  • Code enforcement. The value will always be correct as it is enforced by code.
  • Simplify executives. It is very easy for even a non-coder to read and verify the above line is correct.


  • Smart contract dev is slow. It may take several months to build and formally verify a new contract. Governance is moving faster and faster and we may need to adapt quicker than that.
  • Increases gas cost.
  • Merging high-level governance constructs into the actual code is maybe not a good idea for separation of concerns.

Instant Access Modules

The other piece here is that we could just wait for Instant Access Modules which gives governance a way to vote for short-term parameters changes outside of the weekly executive cycle. These modules would be similar to Method 2, but they occur outside of the arbitrary executive. We also get the added benefit of removing the contention in bundled weekly executives. I’m not sure of the timeline for IAMs, but it seems like it may be good to put these in place sooner rather than later.


I think this is likely a good idea, but am fairly strongly in favour of option 1. I don’t think we should be trying to tightly couple code/implementation details with governance layer abstractions.

I think the flexibility Option 1 provides trumps simpler executives. Moreover, this is mostly a matter of convenience, rather than a fix/system improvement, so the fact there is no enforcement is not a blocker imo. The values can be derived (if laboriously) from other on-chain information, my understanding here is that it’s just about producing clear on-chain values to match the terms used by the hoomans…


From the foundation side we were planning to create a parameter storage MIP that would have a similar function to the forum post you’re currently maintaining. Formalizing the weekly cycle will also go a long way to clear most of the current confusion, since it is mainly caused by ossification of the weekly cycle.

The IAMs will come eventually, but it will take a lot of time so it is definitely a good idea to try to clean things up before them. Ultimately I also expect that they will actually create even more “meta-complexity” than not having them, so I think it is very good to have an effort in the community to get a holistic view of all the on- and offchain parameters and when and how they’re changed