HomeLearnContributeFundingForumChat
    HomeLearnGovernance
    Governance Risk Framework (Part 3)
    Governance Risk Framework (Part 3)
    Part 1 of this three-part series covered the stablecoin universe, defined decentralized risk management, and outlined the governance structure around the risk function.
    Part 2 took an in-depth look at the risks underlying the system, describe how parameters in the MakerDAO system encapsulate those risks, and finally, outline the models that are most appropriate for measuring and managing those risks.
    Part 3 will map out the decisions that Maker holders will need to make, the support they'll get to make those decisions, and the voting process for managing the risk function.

    The Role of Maker (MKR) Token Holders

    This section describes the role of Maker (MKR) token holders in governing the Maker Protocol.
    MKR token holders are responsible for governing the system, establishing the status quo, and defending against proposals that don't support the overall objectives of governance.
    Governance describes how an organization is controlled and who is accountable to the stakeholders of that organization.

    Proposals

    Proposals are introduced to the community, discussed, and put up for a Governance Poll and Executive Vote as necessary.
    Proposals may be divided into two categories:
    • Proactive proposals suggest changes to the system and provide a timeframe for executing those changes.
    • Reactive proposals are made in response to changes in the state of the system.

    Voting

    After a proposal has been debated and considered by the community, resolution is achieved through on-chain voting.
    There are two types of votes:
    Governance Polls are time-based and used to signal the general intent of MKR token holders. Proposals are put to a "yes" or "no" vote and may be voted on for a set period of time. Governance Polls are generally enough for one-off proposals.
    Executive Votes use Continuous Approval Voting and are used to vote on what the most current state of the Maker Protocol should be. Proposals are put to a "yes" or "no" vote and may be voted on for a set period of time.

    Continuous Approval Voting

    Executive Votes use Continuous Approval Voting, which means the voting process is used to maintain the state or "continuity" of the system rather than introduce new and various initiatives as is the case with Governance Polls.
    Imagine that all one million MKR tokens are in the voting construct, with a majority of the tokens in one proposal that reflects the current state of the system. The remaining tokens could then be distributed throughout a collection of new proposals wishing to challenge the state of the system.
    Given the overall distribution of tokens, the status quo of the system will likely remain because the majority of the tokens are still voting for the current state.

    The Value of Maker (MKR)

    The value of the Maker (MKR) token depends on the quality of its use by MKR token holders in governing the Maker Protocol.
    Holding MKR creates an incentive to support effective governance because effective governance leads to inflation in the practical value and hypothetical price of the token.

    Responsibilities of MKR Token Holders

    Majorities rule and no quorum is required to pass a vote.
    The lack of quorum incentivizes all MKR token holders to participate in votes and prevent bad proposals from passing a vote with a low number of participants.

    Governing MakerDAO requires awareness 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 constant involvement

    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 MakerDAO requires iterative change

    The Maker Protocol is based on scientific governance and the system gets better by continuously being challenged and changed. A foundational component of the scientific method is empiricism, which states that we should always be validating or challenging hypotheses with data.
    Changes would be expected to have material marginal benefits at first and 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.

    Governance Security Module

    The Governance Security Module mitigates the effects of detrimental proposals in the Maker Protocol by instituting a delay before executing the outcome of Executive Votes.
    The new code is encapsulated by the module before deployment to the system and held for final consideration for 24 hours, during which all stakeholders may review the code to ensure the integrity of the system, especially the stakeholders responsible for Emergency Shutdown.
    If the code is reviewed and considered detrimental to the system then the system will be shut down before it can be deployed.

    Emergency Shutdown

    Any action, deliberate or not, that is detrimental to the system will be countered with a shut down of the system.
    Both the Governance and Oracle Security Modules institute waiting periods for identifying and preventing the execution of harmful actions before they affect the system.

    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 in MakerDAO. The tools created may focus on the entire risk process or a single part of it. The team then displays the functionality of the tool with a verifiable and easily-accessible dataset.
    The Risk Team then makes the tools available for MKR token holders to assess through an advanced UI or a downloadable worksheet. The tool set should include all the necessary documentation.
    The procedure required to vote in a new Risk Team is as follows:
    1
    Risk team describes and demonstrates their set of tools. This includes interacting with MKR token holders and other Risk Teams.
    2
    When the Risk Team is confident that the tools are understood, they should formally submit their tools to be included.
    3
    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.
    4
    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, Maker Chat or an internally created board).
    5
    After the period of consideration, the proposal will be open to the voting period (e.g. two weeks).
    6
    At the conclusion of the voting period, if the proposal amasses the most positive votes, it is successful, and the Risk Team is accepted.
    7
    Thereafter, the value of the risk parameters generated by that Risk Team will contribute to the Executive Vote by default. The nominal value will not be voted on but whether or not it should be included in the new state.
    8
    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, providing insight into 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. The sequence for the Governance Vote will be:
    1
    The collateral type will be presented one or a group of Risk Teams, including the qualitative and quantitative assessment of the collateral type.
    2
    The submitting Risk Team, or group, will formally submit a proposal to accept the collateral type into the system.
    3
    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).
    4
    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:
    1
    The qualitative and quantitative assessment of the collateral type will be updated with any new information and made public again.
    2
    The submitting Risk Team will then at the quarterly voting date, submit a proposal including the nominal values for the collateral type.
    3
    Since the proposal is in the continuous approval voting system, the proposal will need to attract the majority of votes.
    4
    As soon as the proposal becomes the dominant proposal with the majority of votes it will be initiated.
    5
    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.
    6
    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.

    Conclusion

    As a growing ecosystem, governing MakerDAO requires features to help maintain the system and ongoing input from its governing body.