Mandate: Risk Teams

Mandate: Risk Team


Risk teams are ecosystem participants responsible for managing the various risks in the Dai Credit System. They are tasked with managing the collateral portfolio and recommending appropriate monetary policy while adhering to the principles of scientific governance. Due to the decentralized nature of MakerDAO, there are a number of considerations the community should discuss surrounding the onboarding and management of risk teams.

The Maker Foundation is proposing an operational framework intended to guide both MKR token holders and risk teams through the governance process. After a period of one week, (set aside for debate and iteration), the community will have the opportunity to formally choose to accept or reject this proposition in a governance poll. Acceptance of the proposal will signal the ratification of this mandate and the associated processes and procedures.

Examining the Landscape

The need for risk teams is best understood following an analysis of the core components of the Dai Credit System. We begin with a brief recap and the risks contained within.

MakerDAO is an Ethereum-based DAO that operates the Dai Credit System, a permissionless loan facility. The Dai Credit System issues the cryptocurrency Dai, a stablecoin designed to track $1 USD with low volatility. The core function allows users to self-issue Dai-denominated loans against collateral deposited into smart contract-based escrow. Collateral can be retrieved upon repayment of the outstanding Dai amount plus an associated Stability Fee. This architecture poses two pressing concerns. Where does Dai source its value, and what compels it to remain pegged to USD? The answers to these two questions are the focal points of most risk analysis surrounding Dai. To better understand these risks we briefly explore Maker’s internal mechanics.

Dai stability is dependent on a system of carefully crafted incentives. At the core is the collateral portfolio, a pool of on-chain digital assets that back the Dai supply. While the collateral presents a source of value, additional heuristics are required to maintain a soft peg of $1. In particular, the Dai Credit System incentivizes arbitrageurs to buy and sell Dai in the open marketplace. This arbitrage is supported by monetary policy adjustments that influence the supply and demand for Dai recursively until Dai has returned back to its target price. Market makers have come to rely on these Stability Fee changes, and as a result supply the necessary liquidity to minimize outsized deviations.

In extreme events, 1 Dai can be redeemed for $1 worth of collateral through a process known as Emergency Shutdown. However, collateral values can sometimes fluctuate dramatically. If they were to suffer a sharp decline in value, the settlement feature enabled by Emergency Shutdown may not allow for full redemption. As a last line of defense against volatile asset prices, a buffer in the form of MKR tokens exists to soak up undercollateralized Dai. The distributed set of MKR token holders (“MTH”) are ultimately the group motivated to ensure the successful operation of the Dai Credit System.

MKR token holders coordinate themselves using a decentralized governance process through which they evaluate and select appropriate collateral assets. The success of this endeavor is strongly correlated to a proficient risk evaluation of the collateral set. A failure in due diligence or coordination will result in severe losses for both end users of the protocol (in the form of declining Dai price) as well as MTH (in the form of MKR dilution). While the incentives for MTH are clear, executing the plan requires additional work.

The Need for Risk Teams

There is considerable overhead with respect to quantifying risk in the Dai Credit System and managing it appropriately. It is not practical (nor necessarily advisable) for MTH to directly analyze it themselves. A simple and intuitive solution is to outsource risk specialists who are tasked with evaluation of the risks. While the traditional model of a centralized risk function could operate as a bootstrapping mechanism, we also propose a more robust and decentralized blueprint.

The primary idea is to create the Decentralized Risk Function, a process by which distributed teams of independent risk specialists are incentivized to exercise due diligence on the collateral portfolio and create models for appropriate monetary policy. The decentralized model affords us a near limitless talent pool, blanket coverage, and uninterrupted operation. Additionally, decentralized risk teams are designed to be resistant to capture from biased ecosystem actors; risk teams operate solely for the benefit of MTH.

Through the governance process, the MTH are responsible for managing the operational aspects of Maker risk teams. Here we propose a set of guidelines for MTH through which they may oversee risk teams. Immediately, there are several operational details that need to be addressed:

  • What are the types of risk that need to be managed?
  • Are there different types of risk teams?
  • How does one ‘become’ a risk team?
  • How do they create and submit risk models?
  • How are they compensated?

Types of Risk

There are three broad classifications of risk in the Dai Credit System: collateral risk, monetary policy risk, and exogenous risks.

Collateral Risk

Collateral risk refers to the likelihood of an event where a sudden asset price decline triggers the liquidation of a Collateralized Debt Position (CDP). As mentioned above, the primary assurance for Dai holders is the collateral portfolio. Naturally, a comprehensive understanding of all collateral assets is a prerequisite for proper risk management. Qualitative factors, market liquidity, and recourse methodologies are all in scope and must be carefully analyzed. As a simple example, because illiquid or fundamentally risky assets have a higher predisposition to sudden crashes, a proportionately higher risk premium must be assessed.

Monetary Policy Risk

Monetary policy presents the second major risk classification, refers to managing the supply and demand for Dai. In spite of the quality of the collateral evaluation, the Dai price is still subject to the whims of the market as CDP creators (generators of Dai supply) may not perfectly align with Dai holders (representing Dai demand). Risk levers such as the Stability Fee and Dai Savings Rate can be used to influence both CDP and Dai holder behavior in order to facilitate a market equilibrium at $1. Because the supply and demand for Dai fluctuates based on a variety of market factors, creating an accurate model requires a sound understanding of economics, statistics, market psychology, and more. For example, in Single-Collateral Dai there is clearly a relationship between the ether price and the Dai price. Analyzing this correlation in order to make optimal policy recommendations is an important function of decentralized governance.

Exogenous Risks

Finally, exogenous risk refers to a spate of additional risks, among them oracles, governance, and more. Oracle attacks, or the presumed susceptibility of the collateral price feeds, must be well understood. For example, to what extent can an attacker siphon value from the system if they were to subvert the price feeds? What would the appropriate countermeasures be in such a scenario? Another type of exogenous risk is threats to the governance process. Social attacks or improper procedures might necessitate an Emergency Shutdown to preserve the legitimacy of MakerDAO.

Types of Risk Teams

Not all risk teams will undertake the same duties and job functions. Because different analysts will have distinct specialties and skills, it is helpful to categorize them accordingly. However, it is our assumption that a rich ecosystem of specialized risk teams will develop over time and when needed. For now, we define the broadest types of risk teams that will work for the DAO. Over time, as the needs for risk assessment become more specialized, we can expect to see additional roles.

Submitting Risk Teams

Submitting risk teams are the most fundamental class of risk teams. They are in charge of computing and submitting risk parameters to the governance process.

The most basic responsibility is to evaluate specific assets or sectors. For example, experts in the cryptocurrency space will examine coins such as bitcoin or ether, whereas traditional risk analysts might find the Security Tokens space more suitable. The goal is to provide an examination of the risks for including a collateral asset into the portfolio.

A sub-class of risk teams might be generalists who are in charge of tying together the various collateral types in a cohesive portfolio. One of the primary responsibilities is to factor in proper correlation coefficients, a task they will likely collaborate on with the other teams. A second critical role is to factor in the appropriate monetary policy. Submitting risk teams will be in charge of suggesting appropriate DSR values, as well as any collateral-specific adjustments that might be required. After construction of the collateral portfolio with the appropriate monetary policy parameters, they can then submit the final package to the governance cycle.

Oracle Teams

Oracle Teams are in charge of developing and distributing oracle backend software, as well as emergency oracle programs. For example, when new collateral assets are added, they must be accompanied with a corresponding price oracle. An Oracle Team is in charge of facilitating the inclusion of that oracle. Lastly, an Oracle Team may oversee the productization of any oracle services.

Looking Ahead

In the future, we can expect to see several other classes of risk teams. Supporting risk teams may just work on research or data science, without seeing a model through to the calculation of risk parameters. Blockchain Development Teams might work on upgrading MakerDAO infrastructure. Technical specialists are also likely to find a niche in the ecosystem. The community should slowly increase the scope of risk teams as the Dai Credit System matures.

Risk Constructs

When a risk team is ready to begin work on a risk model, we expect that they adhere to a standardized set of rules. By following strict guidelines in terms of how a risk assessment is conducted, MTH can more easily vet the legitimacy of the process. In this section we propose some principles that every risk model should abide by, along with a description of a sample model. Collectively, this package is known as a risk construct.

Scientific Governance

The guiding principle for all risk constructs is the notion of scientific risk governance, a process by which all risk parameter suggestions are supported by appropriate financial models and data analytics. We propose a set of principles or qualities that scientific risk constructs should comprise.

  • Comprehensive A risk construct should be exhaustive such that all relevant classifications of risk are considered and reviewed. A risk team must delve into the fundamentals of the organization, consider the value proposition of the collateral, and evaluate any potential risks. In the context of monetary policy, appropriate models must be applied that harmonize the exogenous factors impacting the Dai price.
  • Scientific A risk team must be rigorous and scientific in its methodologies. While subjective reasoning can often be an unavoidable part of a risk evaluation, general models should be designed to guide a risk team towards being as objective as possible.
  • Standardization A standardized template adhered to by all risk teams allows MTH to review a diverse set of due diligence reports that can easily be compared with one another. The goal is to eliminate any potential oversights or unintentional biases by individual risk teams such that the MTH are left with only an objective evaluation of the collateral.
  • Reproducible Critically, a model must be reproducible in nature. This entails making data and code publicly available. Third party auditors should be able to independently run the model on a publicly-sourced data set and arrive at the same conclusions as the risk team. A scenario in which MTH cannot verify the legitimacy of a particular risk team’s risk parameters jeopardizes the integrity of the Dai Credit System.

With the scientific governance principles squarely in place, a risk team may continue on towards an operational risk assessment of the proposed collateral type or monetary policy. The composition of a risk construct should contain at a minimum the following: data set, general model, and applied model.

Data Set

Risk teams should use a transparent and auditable data set for the purposes of risk models. The source of the data should be clear. The data set should also be hosted somewhere that it can be downloaded by independent risk analysts. For example, trading data used for liquidity analysis should be included as part of the risk construct. Additionally, any transformations made to the data (such as wash trade filtering or any other types of averages) should be specified.

General Model

The general model is a representation of how a risk team intends to evaluate an asset or other part of the risk function. For example, proposed valuation models, heuristics, and fundamental analysis should be described in detail. Cryptoasset evaluations would require generalized frameworks on how to value various classes of tokens. DSR formulas should be accompanied with detailed and annotated statistical models.

The general model at the core should contain three parts:

  • A framework for fundamental analysis or due diligence. How does one go about evaluating a cryptoasset’s fundamentals? How does one think about DSR changes? The ideas and models behind a risk team’s line of thinking should be described.
  • A scoring framework for collateral assets that enables a standardized approach for converting qualitative analysis into numerical outputs. This is achieved through a ratings-based methodology.
  • A quantitative model that describes the process for computing risk parameters such as the Stability Fee, Liquidation Ratio, DSR, etc. What types of financial models are used? What are their tradeoffs?

MTH are limited in the number of collateral types they may process in a given time period. The general model can help determine which assets should be given priority as approved assets make their way into the collateral pool. The general model acts as a natural filtration mechanism where collateral types are ranked against one another for prioritization purposes.

Applied Model

The applied model should be a specific implementation of the general model. For example, if a risk team wishes to evaluate ether they would apply the principles and evaluation framework presented in their general model. The final risk model should, in some regards, operate on rails. A valid data set in conjunction with a risk analysis framework presented in the general model should result in a deterministic set of risk parameters.

One key consequence of this process is that governance would debate only the validity and strength of the underlying general model (and associated data set), but not the output. If a particular model results in risk parameters that are deemed undesirable after the fact, they cannot be changed arbitrarily. Instead, governance must revisit the general model and debate whether or not it is of sufficient quality, and discuss why it was allowed to be ratified in the first place. It is imperative that general models not be changed after being voted in. Deliberately ignoring key aspects of the general model would result in a failure of the governance process.

It is important to stress that the role of a risk team is to merely provide suggestions for risk parameters. Ultimately, MTH are the ones who vote in parameters that constitute the Dai Credit System. They are the group solely responsible for governing the Dai Credit System.

Onboarding Risk Teams

The final section of this document surrounds the onboarding and management of risk teams themselves, along with the process by which they submit risk constructs. Due to the decentralized nature of MakerDAO, it can be surprisingly difficult to foster an efficient process for handling risk teams. A number of edge cases must be considered before pushing forward. Therefore we suggest a number of operational constraints designed to protect against potential governance attacks on the ecosystem.


Qualified risk analysts who wish to contribute to the Decentralized Risk Function should follow an application process in order to become an official risk team. A candidate risk team would begin by publicly posting credentials to the MakerDAO Forum, resembling a formal engagement process. For example, prior experience, team members, and other qualifications should be surfaced here.

In conjunction with the credentials, a candidate risk team should provide a detailed proposal outlining the type of risk work they would like to do. This General Proposal (GP) might outline a risk construct for ether or a new methodology for calculating the DSR. It is expected that the GP would include a desired compensation amount, similar to a contractor agreement.

Bootstrapping the Application Review

Due to potential overhead and friction involved with a candidate risk team negotiating terms with a decentralized organization, the Maker Foundation will help bootstrap the process by dealing directly with risk teams. The Maker Foundation will review General Proposals and also compensate these teams directly.

This bootstrapping phase is intended to facilitate the growth of risk teams until a robust decentralized framework for proposal review and Stability Fee compensation can be put into place. We strongly recommend the community begin exploring operational frameworks for how they might like to see this process evolve.

Long Term Vision

We can also opine on what the longer term vision might look like. Upon submission of a General Proposal, MTH, in their governance capacity, will then have the opportunity to review them as part of its regular governance cycle. If a GP is approved, a risk team may then begin work on the risk construct. One of the edge cases to keep in mind is a risk team trying to immediately push through new risk parameters that have not undergone sufficient review by the community. To this end, we propose a concept of ‘lead times.’

Lead times are essentially delay functions that should be respected before a risk team may progress through the governance cycle. After a GP has been approved, we suggest that a minimum of one month to pass before a candidate risk team submits their general model to the community. At this point, the community should review and give feedback on the general model. We recommend an additional one month of discussion (and iteration) on the general model prior to submitting the final risk construct into the governance cycle.

The length of the lead time need not be a fully rigid framework. The community can decide if special circumstances allow for standard convention to be suspended. However, the risk that a proposal hasn’t had enough time for consideration needs to always be taken into account. It is not difficult to envision potential governance attacks from malicious attackers trying to rapidly push through risk constructs.


When a risk construct is approved by MTH, it can be said that the risk team has also been approved. Additional risk constructs submitted by the risk team may potentially flow through the governance cycle faster, especially if they fall under the same general model. Risk constructs based on an entirely new general model should begin the approval process from the start.

At the inception of Multi-Collateral Dai, the Interim Risk Team will post a risk construct for the initial collateral set. Approval of this risk construct will officially ratify the Interim Risk Team.


Many details for this coordination process will likely emerge organically over time as the governance process improves. As the risk community expands, a number of questions should be explored as we iterate this framework:

  • Performance review is an important aspect of risk team management. How can the community facilitate this process?
  • A risk team will likely build up a reputation based on their performance, and stronger risk teams will naturally have greater influence in the parameter selection process. Should this be a formalized process with rating points? What privileges do highly ranked risk teams have?
  • How can we design decentralized review and compensation framework for candidate risk teams?

If this mandate is accepted by the community, it will signal its support for the general scope of the initiatives outlined. This mandate should be considered a living document and will be updated based on community feedback.


Most qualified people that can provide Risk Management are experience in analyzing centralized drivers of risk, how do we attract talent that has not been involved with the community/MTH, or is not familiar/experience with the cryptocurrency space? What are the methods we can use to attract outside talent–will the driver be based on compensation?

Will any of the Risk Teams involve/cover scenario-based strategic planning? In other words, measuring risk/exposure and the planning in case of a black swan event–or is that irrelevant since we have the Emergency Shutdown in place?

Otherwise, great work–fantastic write up, thank you for taking time-out to do such.

Just want to make sure the foundation adheres to transparency. Having the clearest possible view of how the foundation goes about this will be super helpful for the DAO going foreword.

I’m down with everything else. I would of liked stronger statements concerning the social components of risk and governance, but its fine for now. That discussion is just starting.

Tl;dr - This is a great document, I have only minor comments and quibbles. I still strongly disagree with the presentation of these proposals and the timeline.

Actual Document Feedback @ cyrus

These two sentences would seem to contradict each other. We can revisit and debate the general model, but we can’t change it? There doesn’t seem to be much benefit to debating its quality if it can’t be changed. I don’t feel there is enough explanation here as to why it is imperative the general model remain unchanged. I feel like I’m missing something.

We can’t selectively ignore/modify the output for specific collateral types: fine, all good, makes sense. But if there is an output we dislike and we can’t change it specifically and we can’t change the generalised risk construct, what is the process for going from a output we are not willing to vote into the system to an output we are willing to vote into the system?

Is it that we can’t change a general model, but we can replace it?

I disagree that there is no responsibility on the Risk Teams here. They are the experts in the area, whereas MTH are the generalists that need to judge provided arguments and models as best as they can. The Risk Teams are providing suggestions that the MTH’s will not understand as fully as the Risk Teams do.

Responsibility is shared. If a general model provides outputs that eventually lead to MKR dilution, it don’t think it’s valid to put the responsibility for that entirely on MTH.

Ahhh! There are so many things for us to figure out.

Bitching about the timeline (again) @ anyone who will listen

Formally protesting this timeline (again.) This is an excellent document, and bar a few minor questions and quibbles, I support it. I honestly don’t think it will take more than a week to debate it. But what if it wasn’t this good? One week is not enough time to turn something unacceptable into something acceptable.

If you are willing to answer, Cyrus, I’m curious to know how long it took you to put this together and get consensus within the Foundation on the contents (not for any nefarious reason, it just feels like more than a weeks effort has gone into this document, either that or you have god-tier document generation skillz.)

I would be happier about this if the Foundation just came out and said: ‘We’ve spent ‘x’ time working on this, we think it’s great. We don’t think it requires a lot of debate but we’re open to minor changes and we’re willing to delay if there are major objections. We’d like you to ratify it in one week.’ That would feel more honest.

My dissatisfaction about the process comes from the implication that the community has time to agree on material changes to this document in one week. I would bet that most interested parties are going to have time to look at it once, and maybe put forward one round of feedback. That process needs to be iterative to actually get results and that takes time.

It’s alive for a week. What if you get conflicting feedback, do you implement it or do you ignore it? Ultimately it is still you (the Foundation) that is making that decision (implement/ignore). I don’t disagree that you should be doing this, we aren’t ready to take the responsibility yet. Just please don’t imply that it is more than what it is.

If the timeline is not as fixed as it appears, could you make that clear? Something like ‘Barring significant objection by the community, we will be ratifying this in one weeks time.’

These statements feel particularly ironic considering the current timeline for these proposals. Risk Constructs and General Models are important enough to get one month lead time for discussion and iteration, but this proposal (which is a meta-level above and arguably more important, only gets a lead time of a week.)

I get it, I honestly, truly do: we want and need to launch MCD asap. We need to get all these proposals ratified. It just feels dishonest, like the Foundation’s words are saying one thing (we listen to the community and MKR Token Holders, we want the community to gradually take over the responsibilities of the Foundation) and their actions are saying another (We need this to go through quickly, so we’re going to make a show of listening, but not actually leave time for the community to make more than a token effort).

(Also, I hope it doesn’t need clarifying, I’m not putting this on you, Cyrus. This document is great.)


The document is good, but I agree with the sentiment expressed above by LongForWisdom and his concerns. I expressed more or less the same already in other threads.

I am answering here, however, to advance a possible idea to the issue of “Responsibility” raised by LongForWisdom.

At the end, in blockchain, what ultimately matters are only (algorithmic) game-theoretic balances. So, to give/impose responsibility to the Risk teams I propose the following:

PROPOSAL: The risk teams (but in general, I think, this could apply to all roles/jobs in the DAO) will be paid in MKR (collected using the SF) and such MKR are time-locked for a specific period (e.g., 12/24 months) before they can be redeemed. So that the risk teams would better do a good job and suggest good measures, or they also risk their salary as MKR-holders.

1 Like
  • i think we should open new topic(s) regarding payments.
  • first we should discuss the mechanics of payment (excluding foundation wallets which is finite source)
  • by default EVERY role should be payed, even IGF (rich can choose not to collect his payment)

In my opinion this should be very high on priority list.


Cool idea. Asking employees to wait 12/24 months on their salary seems harsh though. Perhaps we can split it between Dai and MKR? Some agreed minimum living wage in Dai monthly, and then the remainder in MKR and locked for a certain time? This would help to align incentives and would build stake in the system for employees.

Agree 100%, feel free to start a topic and get some discussion going :slight_smile:

1 Like

I got nothing to add, just supporting your points on timeline ridiculousness.

I don’t see much to actually disagree with but I can’t help but feel like the question “How does one ‘become’ a risk team?” is being discussed like a year late. The Foundation, with Steven, Cyrus, … have been talking about Risk Teams over the past year making it appear, to me at least, like there were already several different teams working on risk or at least being onboarded and I find it really strange to see this question pop up just now at this stage of the entire project.

How many different people are actually working on risk right now to get to MCD?

No, there aren’t any secret risk teams in the pipeline, but you bring up some interesting points. In general, there hasn’t been a ton of serious interest in becoming risk teams, although we receive lots of questions and passive inquiries. I suppose it’s difficult given the lack of clarity (which this doc was supposed to somewhat help with), but to be honest there likely aren’t that many people qualified for the current iteration for MakerDAO.

The broader point, however, is that this should be a community initiative, just like other aspects of MakerDAO. While we at the Foundation are helping put some infrastructure in place (creating the incumbent risk constructs, setting the stage, putting out this doc), there are natural limits to our ability to bootstrap. In general, I think it will work out fine and MCD launch will attract natural talent, but I certainly hope the community finds ways to be proactive about this as well.

Agree with your points but imo “we need this to go through quickly” so Dai and MakerDAO does not become irrelevant because of hundreds of competing stablecoins taking market share in the near future… also MCD needs to go live asap imo so that the code can prove itself by standing the test of time.



As in the Governance Facilitator Mandate thread, the primary concerns here seem to be around the packaging of processes, calendars, and mandates into one proposal. In the future, Foundation initiated proposals will be unbundled into multiple sections.


Should the Interim Risk Team Mandate be added to the governance portal for formal ratification by MKR holders beginning Monday Sept 2nd 2019 at 4 PM UTC, ending on Monday Sept 9th 2019 at 4 PM UTC?

  • Yes
  • No
  • Abstain

0 voters

No, there aren’t any secret risk teams in the pipeline, but you bring up some interesting points. In general, there hasn’t been a ton of serious interest in becoming risk teams, although we receive lots of questions and passive inquiries. I suppose it’s difficult given the lack of clarity (which this doc was supposed to somewhat help with), but to be honest there likely aren’t that many people qualified for the current iteration for MakerDAO.

I get that this is a small space with a limited amount of qualified people for but I just feel like there may have been more focus on publicly calling for risk teams. I’ve had the feeling over the past year that “risk teams” were covered only to find out now there are only a handful of people, which I highly appreciate and respect to be clear, working on this.

The broader point, however, is that this should be a community initiative, just like other aspects of MakerDAO. While we at the Foundation are helping put some infrastructure in place (creating the incumbent risk constructs, setting the stage, putting out this doc), there are natural limits to our ability to bootstrap. In general, I think it will work out fine and MCD launch will attract natural talent, but I certainly hope the community finds ways to be proactive about this as well.

We as community do have a role to play but it’s hard to come up with an actual plan if we don’t know the needs or things that could use extra community support.

Yeah, no disagreement from me here. I also wish things would move a bit faster. Maybe that’s my fault. But in any case, I think now is when we have reached the point where “there is a plan.” The next step is to go out and find risk teams.

I think part of the reason for having dragged our feet can be attributed to lack of quality collateral even available. Hard to get quality risk analysts to leave their current jobs to come work on a highly risky pilot program that may or may not pan out, or for STOs that are nowhere to be seen, etc etc. I think it’s a bit of a chicken and egg problem. Once there are highly desirable collateral in the pipeline, then it should be easy to incentivize (and compensate) risk analysts to come do the work.

1 Like

The formal governance poll is now live: