Crash "in slow motion" scenario analysis


Following all the discussions around VaR and our box parameter, I wanted to provide another perspective on what can hit MakerDAO in case of a crypto crash in slow motion. Results can be taken as similar in magnitude to the excellent VaR model presentation (which works differently).

Model assumption

The model (sources in Scala) focuses on the box issue of MakerDAO. With a box of 15M we can liquidate only 15M DAI per tranche of 6 hours. It is understood that with the OSM we have a lag of 1 hour to react, meaning that people can possibly mint DAI by assigning less collateral because the system is still relying on the previous value. Vault owners also have a 1-hour period before liquidation during which the ETH price can continue to drop, increasing the possible loss of Maker.

Model assumptions:

  • Box is 15M DAI
  • Each vault is modelized as a 15M DAI vault with a collateral ratio depending on the vault type (e.g. uniformly from 150% to 450% for ETH-A). One vault is liquidated every 6 hours period.
  • Each vault can be managed by the user before liquidation (by default 30% of ETH-A vault and 50% of ETH-B vault).
  • ETH prices drop in a linear fashion then stay at the low level. The base case is an 85% drop in 85 hours (1% decrease per hour). This is a black swan scenario, but it should be safe if we really liquidated after one hour.
  • All liquidations are done with the ETH market price (i.e. a super competitive Keeper environment)
  • Liquidation profits are taken into account when applicable.
  • The model is a simplification and we assume there is no significant bug in the model code.


Base case

With the current situation (850M ETH-A, 50M ETH-B) it would lead to a 200-250M DAI loss. The X-axis of the graph is hours (so 12 days in the chart below)

Drop impact

If the drop is only 70% (1% drop for 70 hours, then price stability) we end up break-event. What is interesting is that we start by making money, then losing some to end up flat. Quite a roller coaster with an insolvency event for MakerDAO.

Management impact

If instead of 30% of vault users managing their vault, we have 50% that don’t fall into liquidation, this impact quite positively the P&L with a loss reduced to 70M. It’s still a big loss (7 times the expected surplus buffer).

ETH-A increase to 1.5B

Increasing ETH-A to 1.5B DAI would increase the loss to 400M DAI.

ETH-C for 650M DAI

Instead of increasing ETH-A we can create a facility with a LR of 200%. For the modelization, we expect a collateral ratio uniformly distributed from 200% to 500%.

The loss would be reduced from 400M DAI (ETH-A increased to 1.5B) to 350M DAI (really fluctuating depending on the random numbers). This isn’t a silver bullet because vaults are still stuck in the liquidation pipeline (for days) and ETH price can continue to fall.

Decreasing the LR to 150% (but keeping the collateral ratio from 200% to 500%) doesn’t change much the results in the model. Those liquidations are stuck in the waiting line, it doesn’t matter if they are triggered earlier.

Increasing box to 50M DAI

All the previous results derive from our inability to liquidate quickly enough. If box could be raised to 50M (assuming Keepers have enough capital), the net result would be flat. We would get a lot of profit in the first liquidations then lose this profit for late liquidations.


As seen, even with a slow decrease of ETH price (by crypto standard) would hit MakerDAO strongly. This is due to our inability to liquidate quickly enough, the liquidation pipeline becoming jammed.

While a drop to $230 seems brutal, it would only put us back one year in the past. Another factor is the amount of leverage in the system We host 2.3% of ETH. Selling it in a rush might affect prices. One can argue if DeFi is used to the balanced portfolio concept (having 50% ETH, 50% cDAI for instance), that would trigger buy orders when ETH drops. This mindset doesn’t seem degen-compatible. Liquidity tends to disappear in crashes especially if market participants are already over-exposed to ETH. In such a case, a small box might be a blessing by giving time for the market to recover. It also gives more time for vaults owners to find a solution.

The 70% drop scenario shows that we can quickly lose our surplus buffer even if in the end we end up generating a profit. This is a strong argument to continue to increase it.

I think our main issue is still our ability to liquidate quickly but this will not be a solution good enough if ETH continues to be used as the main source for collateral.


Great to see stuff like this. I had a few comments on assumptions and discussion points.

How does this look if you assume that people aren’t riding the line at 150%? Like, if you start at 180% or 200%, how does this affect the numbers? I don’t think there is a significant amount of debt sitting on 150% for ETH-A for example. Granted, ETH-B is much more aggressive.

Imo this should be modelled more precisely if possible. Can you (should you?) increase this percentage as liquidated vaults get stuck in the queue waiting for box? If the assumption is that 30% of (ETH-A) users save themselves within the 1 hour price update window. How many users should we assume to save themselves within 6 hours? 12 hours? 18 hours? etc.

We should maybe take into account beg here, at least. 3% below market is probably a more realistic best case scenario.

How does this look at potentially more realistic levels. 20M box, 25M box, etc?

1 Like

For 850M line, the model used 57 vaults with CR between 150% and 450% picked randomly. This is why I have run the model multiple times to get something “average”. It seems more or less in line with reality. Would be better to have a model directly linked to the real configuration but it would take way more time to implement.

If you assume the CR is distributed uniformly between 150% and 650%, the loss is reduced from 205M to 115M.

That a tough question. I would say, liquidation are quickly stuck so we can take an 24 hours notice period. Moving from 30% “saved vaults” to 60% would decrease the loss by a little more than 2. It’s somewhat linear until 70%.

That would cost 10M in the base scenario (from 204M to 214M). Not a big deal.

box 15M => 204M loss
box 20M => 160M loss
box 25M => 132M loss
box 30M => 94M loss
box 35M => 70M loss

With a box at 25M and hoping that 60% of the vault will be saved by their users, the loss is lowered to 23M.

box and the monitoring of the user (and a good tooling I guess) seem to be the most important points.

1 Like

Normal distribution might be slightly more in line with reality? Not sure. Agree that doing the actual configuration would be a moderate pain.

Considering our surplus is still less than 10M, it feels like a moderately big deal, but yeah, in relation, I get your point.

Interesting. Thank you!

For sure.

So is the whole system undercollateralized at any point? If not, then we are safe I guess. We cannot prevent the (big) losses, only make them slightly lower.

Nice to see someone even taking a shot at this @SebVentures

After BT I ran a few analyses myself. 70% down is a pretty extreme event and market typically don’t move like that. So I would encourage you to run a few of these using either a stock market plunge (like 1929, or repeat of Black Thursday back to back 25% down moves after 10% a few days before).

The real points to be looked at here imo (and mostly based on my own BT analysis) are:

  1. network access/costs (gas fees I projected to be 10-100x normal with normal being 50-200gwei this could be 500-20000gwei). Possible miner mempool shenanigans.
  2. Keeper liquidity and collateral capital cycling.
  3. Clumping of CRs due to other defi applications using Maker (defisaver, etc. automated CR management)

I would encourage using actual vault sizes and CR’s in such an analysis.

The biggest thing that came out of the my own analysis and included in the BT report was a careful look at what mechanisms can be put into place to reduce the need to liquidate (partial liquidations if they return collateral can bring a vault back above liquidation) and ability to draw on DAI liquidity to buffer the system when the OSM and liquidation prices being paid are massively disjointed. A key lesson learned was that it is a bad idea to be jamming collateral out if the auction price is below 50% of the OSM.

Reasoning here is that if the market price is falling so fast no system is going to be efficient (can’t and won’t happen). A real liquidity crunch since everyone and their brother will be trying to source DAI to pay down loans.

The point here is a real decision has to be made when markets are so disjointed whether to hold collateral until they stabilize and can provide liquidity or to further exasperate depressed ill-liquid markets and who is bearing what risk.

I am glad someone is starting to take a look at this with an idea to minimize losses during such events. I think that other factors will affect the loss/risk profiles than just how much can be auctioned in a certain time.

What I can say is every time I ran numbers on worst case events. Survivable was in the 5-20% range and these were pretty bad (BT cost the protocol 6M on approx 150M at the time or about 4% net. The real losses were more like 13M offset by 7M of liquidation gains or something like that.)

Anything beyond the 20% range was pretty much a unrecoverable wash out event that would affect not just vault holders but also DAI holders unless one thought that the whole system could be liquified by selling MKR (which it probably can’t).

These were the prime reasons I wanted a surplus at least in the 2-5% range combined with a working treasury of at least the 2-5% range of all DAI borrowed. Yes 150M is a big number (10% of 1.5B) but if Maker took earnings and put them into defi itself to earn return and seek to preserve capital it then is straightforward to get to a cash position of 10% of float, and at this point 10% of cap-x.

I thought about writing up a proposal regarding this. Given the huge returns providing liquidity in DeFI 10-20% give or take. I think it makes sense for these protocols to take up to 1/2 of their revenue flows and put them into providing liquidity, preserving capital, and earning return for MKR.

The idea concept was to take 1/2 of surplus after operational expense and bank it across DeFI to earn return and then use the return on the surplus to burn MKR allowing MKR burn to be more consistent and in line with DeFI returns and retaining capital. I liken this to taking money you have to buy a house and instead of paying down the house mortgage at 2% earn return at 6-8%. Use the extra interest to help make the payments and preserve capital for a capital emergency.


"These were the prime reasons I wanted a surplus at least in the 2-5% range combined with a working treasury of at least the 2-5% range of all DAI borrowed. Yes 150M is a big number (10% of 1.5B) "

A 10% ratio is similar to the equity most US Banks hold relative to assets


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.