Using the RiskDAO simulation GUI

R Koschig
Risk DAO
Published in
8 min readMay 31, 2022

Understanding the parameters and outputs of RiskDAO’s framework to simulate lending market liquidation events

Tl;dr

  • We just published our first analysis on Vesta finance, where we presented the fundamentals of our quantitative risk assessment model
  • The simulation GUI lets you browse through the simulation results for different parameter setups (heatmaps and timeseries)
  • In the following we’ll explain how to read these results and the used parameters

The framework

An in-depth description of our quantitative risk assessment model is presented in our Vesta finance system parametrization analysis. In order to assess the risk of different system parameters that the protocol controls, we needed to simulate

  • a sequence of liquidations with time and size
  • the price trajectory of the corresponding collateral asset for every point in time
  • The available market liquidity for selling the collateral. Throughout our
    model we assume that liquidators will only use DeFi markets to sell the
    seized collateral, and hence focus on simulating only DeFi liquidity
  • The available liquidity of the stability pool at any point in time

The price trajectories are derived from an ETH-USDC price timeseries with corresponding liquidation events. We then scaled this trajectory to other collaterals in use/consideration for the Vesta protocol using a ratio of standard-deviations (see details in the analysis report). All other dynamics and scenarios are determined by the following parameters:

The parameters

Price recovery time (half-life, days):

  • What: The time in days it takes for the price to recover half-way to its original path after a liquidation event lead to downwards pressure in price
  • Why: We model the decrease of such impact via an exponential decay function, hence this parameter sets the speed of the recovery
  • Values: 1e-06 ~ 0 means there is no impact of any liquidation event (and hence always ‘immediate’ recovery), but especially for less liquid collaterals we also looked at recovery (half-life) times of 0.5,1, 2, 4 and 10 days.
  • Impact: Higher values mean higher risk as a prolonged time of lower collateral prices, which causes additional ‘stress’ for further liquidation events since the collateral there has less value

Debt ceiling (million $):

  • What: The maximum amount of debt (in million VST/$) that Vesta protocol allows to borrow against the given collateral.
  • Why: The more volume in loans Vesta hands out, the larger impact liquidation events potentially have. Besides the ability to mitigate systemic risks (e.g., bug in the collateral smart contract) that such ceiling provides, it is a necessary boundary to be able to derive a maximum loss.
  • Values: the smallest ceiling is 2m and we increase by multiples of 2 and 5 respectively depending on the collateral with the maximum debt ceiling being 30m
  • Impact: Higher values mean higher risk as the potential impact on the market is higher the higher the liquidation volume.

Monthly liquidation volume to debt ceiling ratio:

  • What: The sum over all liquidations within the given month of the given timeseries of liquidations divided by the debt ceiling parameter value. We refer to it as ‘simulation liquidation factor’ in the report.
  • Why: scaling the liquidation volume of the given timeseries of liquidation events in relation to the debt ceiling is one way to create (reasonable) worst case scenarios (we scale the liquidation sizes not the frequncies)
  • Values: the smallest ratio is 0.5 (so we actually assume a lower liquidation volume than the original timeseries when scaled to the debt ceiling) and increase this with values of 1,2,4 and 6.
  • Impact: Higher values mean larger liquidation sizes and hence more stress and potential loss to the protocol

Stability pool initial balance to debt ratio

  • What: How much capital is in the stability pool at the start of the simulation compared to the debt ceiling
  • Why: A stability pool contributes to a smoother liquidation process. Obviously, if the stability pool funds are negligible compared to the debt this benefit is negligible as well, which is why different settings are explored.
  • Values: 0 means there is no stability pool. If there is one we look at inital shares of 10%, 25% and 50%.
  • Impact: Higher values mean faster ‘digestion’ of liquidation events and hence should result in lower risk/losses. E.g. if we have initially 50% of the debt ceiling in stability pool funds, we can instantly cover a liquidation in the size of 50% of the debt ceiling

B.Protcol share:

  • What: The share of the stability pool that is managed via B.Protocol. As laid out in the analysis report the automation of B.Protocol is assumed to allow for faster recovery of the funds used to liquidate loans vs. the ‘typical’ stability pool staker as also shown with hostorical data from Liquity protocol
  • Why: On top of the stability share, this parameter allows to model the impact of a faster recovery mechanism for the instant liquidity for liquidations that are introduced with the stability pool mechanism
  • Values: 0 means there is no integration of B.Protocol. Other scenarios assume 25% and 50% of the stability pool being managed by B.Protocol, the remaining share of stability pool funds by retail stakers.
  • Impact: Higher values mean a lower risk as there is a faster recovery of stability pool funds back to the initial stability pool balance and hence less potential loss for the Vesta protocol from bad debt.

Stability pool recovery time (half-life, days):

  • What: The time in days it takes the funds of the stability pool that is managed by retail users to recover half-ways to its level prior a liquidation event.
  • Why: For the share of the stability pool that is assumed to be managed by retail stakers (i.e. 1 minus the B.Protocol parameter), empirical data from Liquity protocol suggests that these funds are not recovered immediately after used for liquidations. Rather, an exponential decay function models this recovery decently well, which is why this parameter sets the speed of the recovery
  • Values: We simulated runs with 1, 5 and 10 days recovery time (as shown in the report, the fitted values based on Liquity data varies over time, but had a longer period where ~4 days provided a good fit to the staker behaviour)
  • Impact: Higher values mean a higher risk as there is a prolonged time where the funds of the stability pool have not swapped back into VST (and staked into the stability pool). In consequence, there is longer periods of lower available liquidity for further liquidations.

Volume for 10 percent slippage:

  • What: The maximum amount of collateral (in ETH) one can sell on a sushiswap (like) pool to have a maximum of 10% slippage for such trade.
  • Why: We assume that liquidations only happen, when the liquidation trade is profitable, i.e. when the VST value of the collateral including the liquidation incentive (assumed 10%) is higher than the loan value. When the slippage to trade the collateral back into VST is higher than 10% this is no longer the case (even with stable prices), which is why this parameter helps understanding ‘how much liquidation volume the market is able to digest’ before we see open liquidations and the resulting losses of the protocol.
  • Values: We simulated runs with two parameters per collateral. Lower values are 20m, 150m, 250m, 350m and 400m whilst the corresponding higher value is twice that amount.
  • Impact: Higher values mean less risk since there is more liquidity in the pools and hence less slippage given an equal amount of trading size that is done to trade the liquidated collateral back into $.

The outputs

For each of the ~1.6k different parameter settings we provide two outputs:

  1. A heatmap signaling scenarios/setups with high losses
  2. A timeseries chart of the price trajectory, the liquidation events, the market liquidity and the liquidity in the stability pool

Let’s look at those for the following scenario: DPX collateral, with an initial stability pool balance as large as 25% the amount of the debt ceiling and a 25% share of that managed by B.Protocol. The price recovery half-life time is 0.5 days, the stability pool half-life recovery time is 5 days and the market liquidity allows for trades of up to 350m $ worth of DPX to avoid slippages over 10%.

The heatmap shows 1 minus the maximum loss across the different debt ceilings (x-axis) and ratios of monthly liquidation volumes to those debt ceilings (y-axis) aggregated over the full simulation run of 1 year.

The maximum loss is the maximum relative price difference of bad debt that hasn’t been liquidated (‘open liquidations’) to the market price over the time that liquidation remains open. Hence, we don’t provide the actual PnL impact to the protocol here.

As long as the ratio of monthly liquidation volume to the debt ceiling is 1 and below there is no open liquidations and hence the maximum loss for the protocol from such open liquidations is 0. This changes when when the debt ceiling is raised to 16m, where we see a maximum loss of 10%. However, when looking at monthly liquidation volumes above 1 it gets worse pretty quickly, e.g. with a debt ceiling of 8m and a factor of 2, our maximum loss from those open liquidations is at 35%, hence a value of 0.65 in the corresponding tile.

The timeseries of this scenario shows the evolution of five different metrics:

Green line (left axis): the collateral price (note that this is based on an ETH-USDC timeseries and is only scaled to account for DPX volatility, not for DPX actual current price levels)

Orange line (right axis): the volume of the stability pool (in m VST). It starts at 2m (=25% of 8m debt ceiling), but given the liquidation pressure induced by the high ratio of liquidation volume to debt ceiling never recovers beyond 0.9m (even hits 0 a couple of times)

Red line (right axis): The volume of the available market liquidity (in m VST). It is the paramter ‘Volume for 10 percent slippage’ converted into VST/$ using the initial price of 2000$/ETH (hence 0.7m). The drops corresponding to liquidation events are caused by the model assumption that volume needs 30 minutes to recover to this balance.

Yellow line (right axis): The volume of liquidations (in m VST) in a 30minute interval

Blue dots (right axis): The volume of open liquidations (in m VST), i.e. liquidations not yet closed and hence exposing the protocol to the price risk of the collateral of these bad loans.

Note that this chart shows just 1 month and hence the maximum loss (max drop) is shown as 0 (vs. 35% for the full year in the heatmap above). Another difference is the debt ceiling, shown as 4000 in the above chart: this is denominated in ETH, which is 8m $ at our initial price of 2000 $/ETH.

--

--