Weekly (almost) Narrative on MakerDAO – 17 June 2019

General:

During the course of the last week, the community held off on voting for a change to the Stability Fee (as the winning outcome on the poll showed no change for the then outstanding Stability Fee of 16.5% per annum). The community has maintained the polling frequency for another executive vote with some discussions starting to circulate about modifying the frequency of such votes, with a circular challenge to find consensus on voting frequency (by means of voting for it). At present, the primary (and only) underlying collateral has started to appreciate alongside a broader crypto market rally.

The overall price* of DAI has solidified around its soft peg target of 1.0000 and for the most part stuck to the peg. During the last week, the total outstanding DAI has now expanded to just slightly above 84.5mm DAI following a surge of new DAI being minted.

The above being said, as the DAI price* continues to hover right at the target of 1.0000, we can draw an initial conclusion that most of the market maker inventory has been cleared out with some market makers indicating challenges in fulfilling large OTC orders.

As such, with nearly 2mm DAI being minted and the price not moving in the last week alone, we are rapidly approaching the window when demand is coming into harmony with supply. If the current crypto rally extends into ETH in any way similar to 2017, we should dust-off the discussions on the debt ceiling and prepare for further tightening of our monetary policy.

In parallel to the above, secondary lending markets continue an identified trend to lower their rates somewhat on par with Maker’s rate. As discussed in a previous narrative, the spread between the average of the secondary lending markets and Maker will continue to be compressed as Supply and Demand are brought more into harmony. Important note: The aspect with secondary lending platforms will morph as new collateral types are on-boarded. The expected rate compression should only be compared with a similar collateral type, in this case, ETH when viewed in isolation.

Further, the average daily maker burned (as calculated) is now right at ~51 MKR per day, down from over ~60 after the recent Stability Fee decrease. The total MKR in the “burner wallet” has now surpassed ~1625 MKR. As seen from the previous week, only ~20 MKR have been burned in a timeframe that should have seen ~14x the amount. The P/E ratio (fully diluted less the burner wallet) has also increased as a result of both price appreciation of MKR along with the earning component bring reduced with the recent decrease in the Stability Fee.

Demand:

With the upcoming introduction of the DAI Savings Rate, we need to start polling for / forecasting where to start the DAI Savings Rate. As it is strongly recommended to treat the introduction no different than another other new market force, it is strongly advised to roll-out the DAI Savings Rate slowing starting at 100bps. As the DAI Savings Rate should be viewed as a competitor to traditional saving rates or even United States Treasuries, iterations on the increase post DSR launch should be no more than 25 bps at a time in general (but as further outlined and determined / calculated below which may be less than 25bps).

Referenced Presentation Link (apologies in advance for the manual drawings):
https://docs.google.com/presentation/d/1rNFASmEp6QOWzHVhZZhH_5a9UO4nizGrXErFLX4EIqw/edit?usp=sharing

As outlined in the past in MCD, the Stability Fee for collateral #1 (“SF1”) shall be computed with the following equation:

SF1 = DSR(uniform) + Oracle Fees(1) + Risk Team(1) + VaR_MKR(1)

(Note: While not discounting their value to the system as a whole, for the purposes of this evaluation, we are going to negate the Oracle and Risk Team fees as they should be materially close to zero and thereby negligible when viewed from a macro perspective as they should be basically static with no real change based on the collateral package at hand.)

From the governance call, the topic of MCD and VaR was discussed with no conclusion drawn, but the discussion has started in the community related to how this challenge can be addressed / solved.

This challenge may seem benign but is the cornerstone to risk-management. That challenge is the slow persistent introduction of risk (often unintentional) to a system with no nefarious intent. In this case (and credit to David Utrobin), the concept of “Risk Subsidy” whereby one asset whose risk profile is different, often severely different than another ultimately has its risk being priced relatively the same (or more to the point not staying segregated). The end result is a riskier system.

Let’s step back and lay some core-groundwork. Humans are interesting creatures. For many items, like sight and sound, we perceive a linear relationship with regard to intensity when in fact the actual amplitude is logarithmic (and why it is so easy to damage your eyes with the sun or your ears with loud music). A similar phenomenon happens with risk management as most perceive (or want to perceive) a linear relationship, when it is anything but that!

As a community, we must decide if we want a large asset portfolio that is as uncorrelated as possible or one that is more concentrated. As the Maker project is understood by many, it appears to want to be in the former. That said, having an executive vote to confirm this might be warranted to ensure the community is going down a common path.

Provided that the community is on-board with a large diversified portfolio with a common objective of being as uncorrelated as possible, this by definition will require a large set of collateral types (and collateral packages) each with different risk-profiles (short-term vs long-term to name a couple).

While it is easy as Maker is a crypto project to associate the collateral portfolio as being primarily crypto focused, the end portfolio should be and must be diversified, including all aspects of the analog world (including real-estate pools, mortgage pools, car loan pools, and others). That is to say that initially Maker will more than likely select on-chain assets but must bring on off-chain assets to truly scale and more importantly diversify the risk as much as possible.

While redundant, each collateral package that is used needs to be placed appropriately in the spectrum of risk. One would assume that after an initial VaR_MKR(x) is used, the community would maintain such a rate, and this is where the human factor comes in to play. We as a species like to see clusters, groups, and / or straight lines. Specific discipline will be needed to ensure that collateral package that is deployed to maintain the exponential nature of the risk that is being introduced. Further it is important to “re-calibrate” that exponential nature on the portfolio as a whole on a recurring basis.

While the above is challenge “A”, the below, challenge “B”, represents far more of a concern as it is far more powerful, it has an inverse exponential relationship, is far easier to abuse, and can cause systemic failure.

The DAI Savings Rate

For this Maker credit construct (e.g. warehouse line / repurchase facility), the DSR is the risk-free rate of the collateral portfolio and is uniformly applied across all collateral types and packages. At the same time, it will be increasingly easy to unintentionally lower a collateral package’s VaR_MKR(x) to something less than logarithmic, it is also far easier to inadvertently mis-allocate the percentage the DSR should be applied to a given asset. By inadvertently doing-so, we would be exponentially taking on more risk to the system and subsidizing the risky asset from the less-risky asset. In this case, if we vote on the DSR manually, the misallocation would be to give undue weight to a risky collateral instead of the less risky one. Of course, the even worse scenario is when both happen at the same time.

Following the scientific approach, the DSR which is uniformly applied should be computed as a weighted equation from each of the collateral types / packages that are “on-boarded” rather that purely voted on. That is to say for each collateral package, and depending on the amount of DAI in circulation as a proportion to the aggregate, we should only allow the DSR to be influenced (and then aggregated) based on the risky nature of each individual collateral package. By doing this, we force the segregation of risk into their silos.

What is critical is to have a known Ratio_Rf(A) for collateral package A that remains static for the life of the collateral package OR until such time as the Risk Team (based on conditions on the ground) change Ratio_Rf(A). For clarity, the quotient between the DSR and the VaR_MKR(x) (so in the case of SCD and if we start the DSR at 100bps, the quotient would be 1650bps / 100bps. Thus the Ratio_Rf(eth) as computed today would be 10/165 (or around 6%). Therefore, for every increase to the VaR_MKR(eth), the corresponding weighted DSR should rise by 6%. Only a voted-in risk team should have the ability to change that ratio after “on-boarding”. The VaR_MKR(eth) could change via vote, but the DSR portion shouldn’t be. As it is unknown what the voting portal will look like, it is contemplated that the community could be voting on the end SF(x) or just the VaR_MKR(x).

What remains essential is that algorithmically inhibit the ability to Risk Subsidize a more risky asset with that of one that is less risky unless it is done in a risk-adjusted proportional way. However, the objective is that the subsidies don’t breach the logarithmic nature of the risk-premium or incorrectly use the risk-free rate to absorb the risky nature of one collateral type instead of the system as a whole.

After the on-boarding of a collateral package, it should be put into a state of {insert frequency} (e.g. quarterly) review based on the conditions on the ground. Should the relative risk to the system remain constant, then no changes would be warranted to the Ratio that would govern how much the DSR would be used. That said, should the collateral package be deed to be “less-risky” relative to the portfolio as a whole, then A) a reduction to the net algorithm would occur or B) an automated refinance would occur moving the collateral package to a new CDP (with better ratios) and moving the debt ceiling of the legacy collateral package to zero to organically reduce the exposure. Clearly in the third option where a given collateral package is deemed to be “more-risky” relative to the portfolio as a whole, then the debt-ceiling should be reduced to zero to organically wind down the exposure and create a new CDP with modified ratios that are more in favor of the VaR_MKR(x) instead of the DSR.

What must occur for Maker to succeed is a disciplined approach to “conditions on the ground” risk evaluation compared to the portfolio as a whole. Further, when doing so, we must set what portion of the DSR per collateral package will be used to stabilize the system as a whole.

It is in all MKR holder’s interest to avoid the equivalent of a bank bailout (MKR being diluted) to cover the losses for a risky asset that was incorrectly priced as a safe one. The easiest way for this to occur is for a misallocated use of the DSR where it was used to absorb risk when it shouldn’t have been, rather the borrower that was using risky collateral should have been paying a higher risk premium because of his / her risky collateral.

Time / conditions on the ground / experience / oracle updates, are the only true ways we will get the SF down (on aggregate) across all collateral types. Bluntly using the DSR to cause lower rates comes with the sacrifice of embedded risk.

To quote a previous narrative,

“So while the DSR initially was viewed as somewhat the savior to elevated interest rates, it cannot remove the risky nature of the underlying collateral; therefore the rates associated with that collateral should be elevated until such time as the collateral is no longer as risky.”

If we go down the path of de-risking a risky-asset using the risk-free instrument, we are starting to run a marathon by putting our shoes on the wrong feet when we start. This iterative process will require constant vigilance for as long as the system is being used.

The above being said, it is not the intention to reduce or take the risk-team’s thunder rather the exact opposite. The risk teams will play an absolutely essential role, now and for as long as this project operates. The objective of this post is to shine a light on the systemic risks when using the singularly most powerful tool in the arsenal (the DSR) aside from an emergency shutdown and more importantly why it is essential to algorithmically determine the DSR to ensure collateral assets are “siloed” into risk classifications (which were determined by the Risk Teams). Thereafter, any changes to those “silos” should rest in the hands of the Risk Teams.

Recommendations:

It is expected that the DAI Savings Rate contract will be an essential metric to gauge and estimate demand changes. As such, it is important for future PID algorithm optimization to gather as much demand side information as possible, hence the logic to start slow and iteratively determine the market correlation and sensitivity.

As each time we introduce a new asset type / class / “package”, the DSR and the VaR_MKR(x) will need to update the parallel calculation and the PID as well. In a continuation of the general theme, it is recommended to establish a workgroup to start the logic on a Machine Learning PID Control System** tool to help with signaling. A small group is already coming together with help presently anchored by Vishesh, Alix, and me. That said, the challenge is ever present and impacts all of us. Please connect with us to volunteer some cycles on Rocket Chat or on Telegram.

Summary:
The DSR is probably too powerful for us to vote on directly, especially in the long-run as more and more assets mint or burn DAI, determining which direction to move the DSR and by how much must be scientific in its approach. The allure of a short-term “sweep the risk under the rug” fix will be an exceptionally potent lure. What is far harder is to appropriately charge the risky collateral the risk premium that is justified based on conditions (no popularity contest winners for this role). As that value is voted upon by the community, a systemic risk (almost an attack vector) appears. Further our ability to determine whether the voting of an elevated DSR while lowering a specific VaR_MKR(x) is an attack vector will be exceptionally difficult to judge.

Therefore, it is recommended that we either

1) Algorithmically calculate the VaR_MKR(x) for each collateral type and simply vote only on the DSR

OR

2) Algorithmically calculate the DSR and vote on each VaR_MKR(x)

Out of the two above, option 2 is recommended when the DSR is being computed with a weighted average.

Voting on both the VaRs and DSR may prove to be exceptionally dangerous.

* – price being determined by USD fiat offramp via USDC – DAI (at pro.coinbase.com)
** – PID (proportional / integral / derivative) Control System. It is expected that the DAI Savings Rate will be a potent (and more so than the Stability Fee impact on Supply) tool, as such it will be supply leaning (much like an autonomous car that has an alignment issue and drifts to the right, the control system for Maker will unlikely be symmetric between supply and demand).

NOTE: Not a part of the Maker foundation, just my $0.02 and not intended as advice in any capacity.

Top 250 MKR holders = 688702.031
1d 🔺: 50.445
1wk 🔺: -98.802
Live STBLTY Fee: P/E (dilut.) 53.52 – P/E (w/o dev. fund) 39.65
FCST 50bps STBLTY Fee (VaR MKR burn portion): P/E (dilut.) 1775.24 – P/E (w/o dev. fund) 1331.43