Governance Risk Framework (Part 1)
This section describes the risk management in Maker and the role of Maker token holders in managing it.
The goal of governance is to establish the effective processes for protecting the integrity and stability of the Maker system. We aim to achieve that goal by building a decentralized, open, scientific risk management community.
Introduction
This section is divided into three parts.
The first will define what a stablecoin is and classify different types. It will then introduce the concept of ‘decentralized risk management’.
The second part of the section will address how decentralized risk management is initiated and implemented by the first risk team, a template model team, the internal risk team of the Maker Foundation.
The last part puts it all together for Maker token holders, by mapping out the decisions that Maker holders will need to make, the support that Maker holders will get to make those decisions and the voting process to follow to manage the risk function. It is the objective of this series to gain an understanding of the risk management function and the contribution Maker token holders make in managing it.
Stablecoins
Stablecoins are crypto-assets that aim to maintain value relative to a specific asset or basket of assets.
The stability implied in the name is created through a mechanism of dynamics that attempt to keep the value of the token steady with some given reference point.
In most instances, that reference point is the United States dollar but could be extended to any other asset (Euro) or index (CPI).
Types of Stablecoins
Currently, three mechanisms or types of stablecoin have transpired that attempt to implement this:
IOU
The IOU organization is asking the user to place their trust in the traditional centralized system;give them an asset (usually a $1), they will keep it with a centralized custodian and will provide you with a token in return. If you want your asset back, give them the token and the centralized custodian will give you your asset back. The user explicitly trusts that the custodian will look after its assets.
Seigniorage Shares
Seigniorage share or Algorithm-based stablecoin solutions ask the user to place their trust with them. If the price of the token is too high, they will increase the supply and reduce demand. If the price is too low, they will increase demand and lower supply. The user explicitly trusts that they, or the mechanisms deployed by the organization, will respond in a timely and appropriate fashion to keep the system and by definition their token stable.
Collateralized
Collateralized organizations ask the user to place their trust in the value created by the blockchain. If the user believes that the economy of the blockchain will flourish then so will the tokens on the blockchain. Those tokens are then used to collateralize the supply of stable coin into that economy. Regardless of the governing dynamics used for stability, users place their trust first and foremost into the pledged collateral before anything else.
The most significant difference between these solutions is where you place your trust as a user and, by extension, how you define the character of that stablecoin.
Dai - A Collateralized Stablecoin
Maker allows users to place their trust in distributed ledger technology through the value proposition of the Dai stablecoin.
Dai is supplied to the Ethereum blockchain economy by way of a lending mechanism, whereby a user borrows Dai and increases supply through on-chain transactions.
To facilitate this lending, Maker has created a smart contract called a Collateralized Debt Position (CDP).
The purpose of the CDP is two-fold; to accept pledged collateral tokens and to make a Dai credit facility available. Put another way, it provides loans and attempts to mitigate credit risk at the same time.
Collateralized Debt Position - The Engine of Supply
A Collateralized Debt Position (CDP) is a smart contract designed to minimize credit risk and facilitate collateralization.
Credit or counterparty risk is the risk that a borrower will default on their debt. To mitigate the risk associated with borrowers defaulting, lenders ask for recourse in the form of collateral to be paid before borrowing money.
Collateralization is a fundamental tool used throughout the traditional finance space to minimize or mitigate credit risk. Collateralization occurs when a borrower pledges an asset as recourse to the lender in the event of default on that loan.
Pledge-of-Assets and Event-of-Default
A CDP encapsulates these two ideas and turns the fundamental notion of a credit facility into a Dai supplying mechanism.
Assets pledged as collateral need to be unencumbered and accessible to the lender, meaning the lender can take possession and store the collateral somewhere in the event it needs to be seized.
There is an industry dedicated to this process of pledging assets, ensuring they remain unencumbered, and warehousing them appropriately. This is all done in almost an instant with a CDP.
Defining "Event-of-Default," recognizing when it happens, and taking the appropriate action is again an industry in the traditional space. The CDP makes this a well established and almost instant event to which we can identify and react.
Governance and Decentralized Risk Management
What assets do we use as collateral and how do we define a default event?
Ultimately, we would like to answer these questions through a myriad of competing risk constructs from a multitude of risk teams.
The combination of these teams through competition and cooperative structures, which forms the basis for the Decentralized Risk Management function.
The Goal of Risk Governance
The goal of governance is to establish the most effective way to protect the integrity and stability of the Maker system.
The community is initially being guided by the Maker Foundation and will eventually be led by a multitude of formally-elected risk teams and independent, volunteer risk researchers.
A decentralized risk function’s value lies in its ability to protect against biases and at the same time challenge the status quo and make better contributions.
Forming a Decentralized Risk Management Function
The community envisions a point where the community can rigorously debate a potential risk construct applicable to the system to reach scientific consensus on what is considered the best overall risk construct for the system.
Risk teams will be able to challenge the current construct in place by way of introducing a new construct for consideration.
If accepted, the construct will receive an initial weighting that will determine how that construct will contribute to the overall risk function.
Data should be explicitly defined and may be either exogenous or endogenous to the construct. Exogenous data may be price data or qualitative data obtained outside of the construct, where endogenous data is calculated data from within the system and again used as an input for the system.
Consensus on the construct implies agreement on all processes and production, including the data obtained, the source of the data, and any data transformations that may occur within the construct.
Risk Teams and Their Contributions
As MakerDAO's risk function becomes more decentralized, the risk teams approved by Maker token holders will propose risk constructs to be included in the Maker Protocol.
The output of these constructs will include assessments and risk parameteres for the system.
Risk constructs may eventually include diagnostic risk management models for the entire collateral portfolio. Consequently, we can see how a collection of risk constructs could ultimately cover every aspect of the risk management function.
Outline of the Governance Mechanism
Maker token holders will eventually manage the risk function of the system using its voting mechanism.
The governance mechanism has two functions:
- Proactive Governance includes debate, resolution and automated implementation.
- Reactive Governance includes procedural intervention.
An example of proactive governance is the process of accepting a new token as collateral and deploying the risk parameters associated with it.
An example of reactive governance is increasing or decreasing exposure to a form of collateral due to increases or decreases in liquidity.
Voting
Voting takes two forms:
- Governance Polls provide resolution on a matter or collection of matters. An example would be the inclusion of new oracles or a new risk team.
- Executive Votes change the state of the system. An example would be to vote in risk parameters for a newly accepted collateral type.
Timing of Proactive Governance Votes
There will be three subtypes of votes. Once-off or initialization votes, intermittent votes, and regular votes.
- Once-off or initialization votes start the process for something. In this instance voting for the first risk construct, which explained next, is a good example. The risk management function initially will be represented by the internal team whose purpose will be to create a construct and template for future teams. Thus an initial vote will be required to get this process started.
- Intermittent votes will be irregular and generally will not be expected to have much of a pattern. Voting in new Oracles is a good example; Oracles are not regularly included in the system and thus would fall under this type of vote.
- Regular votes will be votes for matters that are expected. Implementing new collateral risk parameters will be expected to be something that will continually be on the voting roster for Maker token holders. With the expectation of being held quarterly.
Timing of Reactive Governance Actions
The need for reactive governance actions will change as risk constructs are added to the Maker Protocol and changed over time.
These actions relate to the performance of a function, such as an oracle. If an oracle needs to be excluded from the system for some reason, a reactive action needs to be implemented to remove the oracle.
Voting in New Collateral Types
The first step is a qualitative assessment of the token under consideration performed by a risk team or independent risk researcher and proposed to Maker token holders.
Maker token holders use Governance Votes to accept or reject the output of the due diligence proposal and if accepted, the community then records that the token is slated to be included as collateral token in the next Executive Vote.
The Governance Vote can occur at any time during the quarter before the Executive Vote. Every time a new collateral type passes a Governance vote, we add the risk parameters to the roster for the next Executive vote.
Every quarter the collection of risk parameters will be voted into the system by way of the Executive vote, meaning the necessary code will be deployed to the system to update fields and thus the state of the system.
Collateral will change its nature over time and as such if the collateral accepted declines or improves in quality reactive governance actions will be used to adjust the necessary parts of the system. These adjustments are implemented intermittently but congruent with the approved collection of risk constructs in place.
Risk Management for Maker Token Holders
Maker holders have to discuss the merits of each proposal and, if satisfied, vote in the appropriate Governance Polls and Executive Votes.