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.
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:
/** * CHANGING THE BASE RATE TO 3% */ // 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%:
/** * CHANGING THE BASE RATE TO 3% */ intermediateContract.setBaseRate(0.03);
- 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.