The Governance Risk Framework is a series of blog posts. This is Part Three.

Read Part One
Read Part Two

“The ‘something’ that connects the two transactions is called money, and it has taken innumerable physical forms — from stones to feathers to tobacco to shells to copper, silver, and gold to pieces of paper and entries in ledger books. Who knows what will be the future incarnations of money? Computer bytes?

Milton Friedman, Money Mischief: Episodes in Monetary History 1994

“The one thing that’s missing, but that will soon be developed, it’s a reliable e-cash. A method where buying on the Internet you can transfer funds from A to B, without A knowing B or B knowing A.”

Milton Friedman, Interview with the National Taxpayers Union March 1999

Introduction

In this, the final part of the Governance Risk Framework, we outline and note the responsibilities of governing the MakerDAO system. We then put all the pieces together and look at practical examples of governing using Governance and Executive Votes. The objective of governing the system is to provide the best framework to ensure Dai stability. Manifesting a truly decentralized e-cash from computer bytes, hopefully creating a little more than Milton Friedman thought would happen. Before combining the pieces together, we need to consider the concept of governance from the perspective of MKR token holders.

Governance describes how an organization is controlled, and at the same time, describes who is accountable to the stakeholders of that organization. Governing is about striking the balance between what a disparate set of governing groups thinks is best for the organization versus what is actually best for the organization. The added difficulty is that not many can articulate, let alone agree, on what is best. In fact, the complexity of governance depends on how clear or obvious the definition is of “best” for the organization. The less obvious the definition, the more likely groups would form around their own interpretations.

It is because of these groups a new dynamic comes into play. A dynamic that develops from the competition of what is considered the best interpretation to implement, turning into a winner-takes-all modality. Consequently, this results in the need to gather a critical mass of agreement around a popular subjective interpretation as opposed to an open and critical objective debate. Special interest groups form to promote their respective points of view through the act of lobbying. Lobbying seems to be a natural function of these systems so it is not surprising to see it appear.

It is not that special interest groups are inherently bad. However, the hazard in this situation is that the group dynamics may value “winning” over sharing a valid interpretation of the situation and its impact. Consequently, the collective could be directed by those with the most resources and not necessarily by the best direction.

These are not new problems, at the same time, there are no new solutions to these problems. MakerDAO does not escape these problems, but it does reframe the question of what is best, in that it allows for a type of governance — scientific governance — to have the best chance of success.

Proposals and Scientific Rigor

Proposals, as mentioned in the first part of this series take two forms, proactive and reactive. Proactive proposals create something new for the system, while reactive proposals alter that which has already been implemented.

Proactive proposals have a timing element attached to them. The timing is suggestive as to how regular we should expect them and by extension the regularity of changes expected for the system. Proactive proposals could be one-off, generally related to the start of the governing system. Intermittent proposals are more related to the service providers for the system, an example would be the inclusion of a new Oracle or risk team. Regular proposals relate to the structural maintenance of the system, the structural elements that contribute directly to the stability and integrity of the system.

On the other hand, we have reactive proposals, their function is to respond to a state change in the system. Collateral types included in the system may have changed in terms of liquidity and thus may require an alteration to their specific debt ceiling. Volatility may have moved to a different regime for a collateral type or for crypto as a whole and the liquidity ratio may need to be changed. Basically, reactive proposals respond to changes in the system.

Regardless of the type of proposal, the content of the proposal is generally vetted or based on scientific rigor. This ensures that what governing voters need to decide on is the ‘what’ and not so much the ‘how’. The risk teams serve as a good example. MKR token holders voting in a risk team through a governance vote are implicitly agreeing to the models used by that risk team, and thus voting in a risk team is the same as agreeing to the products of their models.

Proposals are introduced to the community, then discussed, and finally put up for Governance and when necessary an Executive vote. The reason for this process is to ensure the highest confidence in the proposal passing. The next section elaborates on this process.

Success through Governance and Executive Voting

A proposal, whether reactive or proactive needs to go through a confidence-increasing process. The proposal needs to be considered, digested, and resolved as being necessary for the system. Resolution is achieved through a successful Governance poll, a resolution that signals the general intent of the MKR token holders. A resolution that shows the intention of the governing community to pass a proposal in an Executive Vote, alleviating as much contention as possible before the proposal is actually deployed to the system.

If the vote is on a one-off proactive proposal, such as the inclusion of a new Oracle, a Governance poll is all that is required. The vote will be binary, either yes or no. In the future graded votes could be included as well as different sub-voting mechanisms. Executive votes too are binary, the decision would determine if the state of the system will be changed. Given that a resolution was reached with a Governance poll beforehand it would be assumed that the resolution would carry to the Executive Vote as well — therefore increasing the confidence that the Executive Vote will be successful.

Governance Polling is Time Based

A proposal open for a Governance poll will have a period of consideration after it has been submitted. If a change is required during that period, the change will be implemented in a resubmission of the proposal, and the period of consideration reset. Consideration is followed by a period of voting, a period that is open to receive votes of yes or no. Regardless of the outcome at the end of the voting period, the result will be recorded in the Governance system. If the proposal does not garner enough positive votes it will not pass and shall remain visible in the system reflecting the percentage voted against it. If for some reason the proposal is not sufficient to go to a vote it may be withdrawn. Either way, a new proposal may be submitted and the process started again. In short, the period of consideration and voting has a predetermined length. At the end of the voting period, the result (yes or no) with the most votes wins.

Executive Voting is Continuous

The Executive Vote, by extension, represents the state of the system. The state of the system, regardless of what it looks like, is always live. The implication is that the state of the system is continuously active and therefore requires continuous governance. To elaborate, imagine MKR token holders have decided on a previous proposal, say one that implements a set of risk parameters, this proposal reflects the current state of the system — regardless of what was implemented. At any time a competing proposal to the system could be introduced. If MKR token holders do not agree with the new proposal they need to cast their vote for the current state of the system, implying that they do not want to see anything changed.

The continuity of the system is emphasized in the fact that a new proposal could be submitted at any time by an MKR token holder. Therefore the system needs to be continually monitored and governed, and thus needs a voting construct that reflects this need. The construct employed by MakerDAO, that satisfies this need, is called the Continuous Approval Voting system.

Continuous Approval Voting

Governance may be considered in terms of where MKR token holders wish to hold their tokens. There are only three places for them, the first is in a wallet, the second is in the voting construct and third is in the liquidity pool construct.

It bears repeating that MKR tokens are Governance Tokens. The reason for the reminder is to emphasize that MKR tokens should, at least theoretically, always be in the voting construct maintaining the status quo of the system. Then the question that remains is if MKR tokens are not in the voting construct, then where would they be and why would they be there? This section will focus on just the voting construct, the sections that follow will consider when tokens are not in the voting construct.

A thought experiment will help to clarify the underlying dynamics. MKR token holders need to govern the system, establish the status quo for the system, and defend against any proposals that seem antithetic to the overall governance objective. Imagine then that all one million MKR tokens are in the voting construct, with a majority of the tokens in one proposal — thus voting for a proposal that reflects the current state of the system. The remaining tokens would then be distributed throughout the collection of new proposals wishing to challenge the state of the system. Given the overall distribution of tokens, it is clear that the status quo of the system will remain because the majority of the tokens are still voting for the current state.

If a proposal is introduced that is clearly beneficial, the inherent value of it would be realized in the system. If the MKR token holders recognize this value, the majority of tokens would shift to this new proposal and implement it as the new state of the system.

At this moment it would help to step back and think how a new proposal could represent a new state of the WHOLE system. The first thing to keep in mind is that if a proposal has gained a majority, then the change described in that proposal will be implemented once and only once. After this, the proposal turns into a “Current State of the System” proposal. Therefore a new state of the system is represented by how it is changed, so a majority of MKR token holders in a new proposal represents the current state of the system AND the change required in the new proposal. Further, to defend the current state of the system MKR token holders are required to keep their votes in this most current proposal that reflects the status quo of the WHOLE system.

To continue with the thought experiment, assume that proposals are continuously being introduced to the system. To govern the system appropriately all MKR token holders would have their tokens in the voting construct, either constantly representing the status quo or moving to the new proposal to unleash its potential value. This is Continuous Approval Voting, where the continuity represents the status quo of the system continuously being challenged and reinforced through ongoing movements of the majority of votes between desired new proposals and the most recent successful proposal.

Placing a Value on Responsibility

The primary feature of the MKR token as a governance token is that the holder represents the accountable party to the system and has a self-referencing fiduciary responsibility to themselves. The distinguishing featureis the fiduciary responsibility to themselves. The incentive for implementing that responsibility is to have a say over the development and growth of an organization that inflates the token value if governance is implemented correctly and deflates if not. The system thus places a value on governance and further increments that value through good governance.

The previous section referenced a thought experiment where we assumed that all MKR tokens were in the voting construct — the Continuous Approval Voting system. Further, it was deduced by using an edge case of continuous proposals being submitted why all the tokens in the voting construct would be needed. Stepping back from that edge case, where proposals are not continuously submitted to the system, what would that mean for the MKR token holders? Assume that an equilibrium has been achieved and that no further proposals are to be accepted into the system. Meaning that the MKR tokens have extracted all the value from the proposals and that its value to the system should remain constant, given no further proposals are submitted. In terms of allocating capital to its best use, an MKR token holder may wish to transfer value to Dai in order to maintain the perceived maximum value extracted from all the proposals.

Transferring value to Dai is a specific liquidation event and an instance of what happens in the liquidity pool construct. The liquidity pool represents all the liquidation vectors available to MKR token holders that believe that a redistribution of resources is required as the MakerDAO system is in equilibrium AND no further material threat to the system is perceived. If new proposals start entering the system again, then previous holders would likely enter the liquidity pool to reacquire their position in MKR and participate in the vote either to help extract value from the new proposal or defend against it.

Holding MKR in a wallet is reflective of the maturity of the system. If the voting construct is not fully developed, secure, or appropriately fluid, and the liquidity construct is not liquid enough, the only remaining alternative is to keep the tokens in a separate wallet.

In summary, given a fully developed and secure voting construct alongside a liquid market in MKR tokens, there should be only two options to consider. Keep your MKR in the voting construct to constantly govern, or turn it into Dai. Considering these constructs are never going to totally satisfy the standards of all holders, one would assume a natural amount of MKR tokens to be held in wallets.

Core Responsibilities of MKR Token Holders

Probably the most important aspect of the voting system to keep in mind is that no quorum is required to pass a vote. Combined with the majority wins tenet, it should be clear that the main responsibility of MKR token holders is to be cognizant of all proposals that enter the voting construct. In fact, the lack of quorum implicitly incentivizes all MKR token holders to be involved. The edge case threat is that an antithetical proposal could pass with a very low number of participants. In this case, it would be assumed that the governance proposal was not clear or mass apathy has set in. Either way, if a detrimental proposal is passed the Governance Security Module would have to kick in. If the outcome is that the proposal is indeed detrimental or a clear attack on the system then an Emergency Shutdown would be implemented before the proposal takes effect. At this juncture, it would be wise to explore what the Governance Security Module is and does, along with revisiting the Emergency Shutdown function of the system.

The Governance Security Module

Once an Executive Vote has passed, a delay period is instituted. The period of delay is the main component of the Governance Security Module. The newly voted upon code is encapsulated by the module before deployment to the system and held for final consideration for 24 hours. During this period all stakeholders may review the code, especially the stakeholders responsible for Emergency Shutdown. The purpose of the review is to ensure the integrity of the system and nothing else. If the code is reviewed and considered detrimental to the system, then the system will be shut down before it can be deployed.

Emergency Shut Down

The system shuts down if it is under attack. Any action, deliberate or not, that is detrimental to the system will ultimately be countered with a shut down of the system. The Governance Security Module is an example of a built-in security measure used to protect the system against debilitating influences and actions. The Oracle Security Module works in the same fashion. Initially, an array of prices are transformed into a single price. The transformation enhances the authenticity of the price used but still doesn’t guarantee it reporting a valid price. In that event, the Oracle Security Module institutes the same measures as the Governance Security Module and gives the system an opportunity to shut down before the detrimental price is enacted.

The main objective of Emergency Shut Down is to align all incentive. Like anything, there are outlier incentives that need to be catered for, it is in these cases that if the outlier incentives do not align with the general purpose of the system the Emergency Shut Down function kicks in.

The Responsibilities of MKR Token Holders

The main objective of governing the MakerDAO system is to align the interests of all stakeholders to the same end:

• • Governing MakerDAO requires being aware of the tradeoff between the incentives of the liquidity construct and voting construct. MakerDAO becomes a better a system if it is subjected to an array of proposals from the governing body that brings a potential increase in value that challenges the inherent value presented by the liquidity construct.

• • Governing MakerDAO requires being constantly involved. There is no quorum requirement, therefore the governing body needs to be always engaged in order to prevent, what would be, a non-representative number of votes changing the state of the system. Instituting a quorum from the outset would seem a better proposition but institutes an injection of central authority. Quorums are essentially a way of representing the importance of a vote, this is subjective, and any predetermined quorums will only represent what a person or group of people consider to be important.

• Governing MakeDAO requires iterative change. The system underlying the provision of the stablecoin Dai is based on scientific governance. A foundational component of the scientific method is empiricism, which states that we should always be validating or challenging hypotheses with data. Ultimately, the system gets better by continuously being challenged and changed. Changes would be expected to have material marginal benefits at first then slowly diminish to negligible marginal benefits. At this point, the system would ideally be in a steady state of equilibrium. Then a regime shift would occur and we would have the next wave of changes. Regime changes should always be expected.

Governing in Practice

Governance Poll Process — Voting in a new risk team

A risk team constructs a tool or set of tools to evaluate risk inherent in MakerDAO. The tools created could focus on the entire risk process or a component of it. The team then displays the functionality of the tool given a dataset, where the dataset is verifiable and easily accessible.

The risk team then makes the set of tools available for MKR token holders to assess. The tools could be made available through an advanced UI front end or simply through a downloadable worksheet. Of utmost importance is that the tool set includes all the necessary documentation.

The procedure required to vote in a new risk team would then be as follows:

• • Risk team describes and demonstrates their set of tools. This includes interacting with MKR token holders and other risk teams.

• • When the risk team is confident that the tools are understood, they should formally submit their tools to be included.

• • A proposal sent to the voting construct will be that submission; implying that the risk team should own some MKR tokens to submit such a proposal. The proposal will be put to a Governance Vote.

• • The proposal will then go through the period of consideration (e.g. two weeks), where any final discussion can be had via Maker social channels (Reddit, Rocketchat or an internally created board).

• • After the period of consideration, the proposal will be open to the voting period (e.g. two weeks).

• • At the conclusion of the voting period, if the proposal amasses the most positive votes, it is successful, and the risk team is accepted.

• • Thereafter, the value of the risk parameters generated by that risk team will contribute to the Executive Vote by default. Implying that the nominal value will not be voted on, but simply if it should be included in the new state.

• If MKR token holders find the values submitted to the Executive Vote are not the same as that which the accepted set of tools implies — the vote will be rejected and the risk team may be voted off from MakerDAO.

Executive Vote Process — Voting in a new collateral type and risk parameters.

A new collateral type added to the system implies the possibility of generating new Dai. The inclusion of a new collateral type should be considered from two angles. The first is the potential that it brings to generate new Dai, the second is the amount of stability it brings to the system. A qualitative assessment of the organization representing the token gives an indication of how robust the token could be. Consequently giving insight to the level of stability it could contribute to the system. A quantitative assessment of the token gives an indication of the risks faced in trading the token in secondary markets, as well as the amount of the token that should be used in the system. Such an assessment would indicate the potential amount of Dai that could be generated as well the market risks of the token.

Every Executive Vote is preceded by a Governance Vote. So the sequence for the Governance Vote will be:

• • The collateral type will be presented one or a group of risk teams, including the qualitative and quantitative assessment of the collateral type.

• • The submitting risk team, or group, will formally submit a proposal to accept the collateral type into the system.

• • The proposal will go through the usual period of consideration (two weeks) and if there is no obvious contention it will go through the voting period (two weeks).

• At the end of the voting period, the proposal will pass if it has the majority vote.

The sequence for the Executive vote will be:

• • The qualitative and quantitative assessment of the collateral type will be updated with any new information and made public again.

• • The submitting risk team will then at the quarterly voting date, submit a proposal including the nominal values for the collateral type.

• • Since the proposal is in the continuous approval voting system, the proposal will need to attract the majority of votes.

• • As soon as the proposal becomes the dominant proposal with the majority of votes it will be initiated.

• • The governance security module will kick in and delay the deployment of code to the blockchain for 24 hours. This is the final security construct that allows a final determination of the security of the code.

• The code is then deployed to the blockchain and the state of MakerDAO is changed.

At this point, the new collateral type is then free to be used as collateral and to contribute to the overall supply of Dai. This covers the different types of voting constructs. In conclusion to this article, we will address the governance decisions to be expected that kicks the system off for Multi-Collateral Dai.

Conclusion — The Next Steps

Governing the MakerDAO system is similar to governing a large ecosystem. There are inherent features that help to look after the system and some that require input from the governing body. No matter how you look at it though, the information pertinent to the system will become fluid and continuous. Requiring constant assessment and governance. Highlighting the need of the MKR token holders to fully understand the depth of responsibility and likewise the benefits of governing the MakerDAO system.

Starting the Multi-Collateral Dai engine is the focus of the ‘next steps’ which include the following:

• • Approving the internal risk team through a Governance Vote. Required in order to vote in collateral types and risk parameters. Prior to mainnet launch.

• • Approving the initial list of collateral types through a Governance Vote. Required in order to vote in and deploy risk parameter values. Prior to mainnet launch

• Voting in the risk parameter values for the approved collateral types through an Executive Vote. At mainnet launch.

In terms of practical considerations for governance, we still need to consider a few things. First, are the actual tools used to calculate risk figures, as well as the method to construct the collateral portfolio as a whole. Secondly, how risk figures from a collection of risk teams are aggregated and deployed to the system. This will be covered in two separate documents, but given that is implemented and the necessary approvals are in place, the full production system starts in earnest and we take this huge step into a new era.