Overview
Xenophon Labs built an open-sourced, agent-based model for simulating the crvUSD protocol under varying stressed market conditions. The model simulates rational agents (arbitrageurs, liquidators, and keepers) interacting with Pythonic representations of crvUSD’s smart contracts as the market prices of various collateral tokens (e.g. WETH) and stablecoins (e.g. USDC) change. The model is custom-built for the crvUSD token; it simulates optimal soft-liquidations, hard-liquidations, and peg keeper updates using realistic routing algorithms that account for market liquidity.
We simulated the crvUSD protocol against a battery of stressed market scenarios, including high collateral volatility and stablecoin (USDC) depegs. In each simulation, we track relevant key metrics regarding the system. Our main metric is the total amount of “Bad Debt” in the system - which is the amount of underwater debt that should have been liquidated, but wasn’t. Using simple Monte Carlo methods, we aggregate the results for each of our metrics across one thousand simulations for each of our scenarios to estimate the underlying market risk exposure.
Using this tool, we tested whether the crvUSD protocol does or does not exhibit excessive risk in periods of high market volatility. We also tested the protocol’s exposure to its peg keeper tokens, such as USDC, and tried to identify “failure cases” where the protocol exhibits too much risk. We built a dashboard to view the results from all of our model runs, which you may use to follow along when reading these results.
In this post, we briefly overview the model, discuss our results, and provide some of our takeaways. For a much more detailed analysis, please read this report.
Contributions
As the model is open-sourced, anyone may fork our code and run their own simulations, or try to build additional functionality on top of it. We welcome any contributions to our repository, please reach out if you need help understanding or running the code. All the assumptions and limitations of the model are discussed in the final section of the report.
Links
- In-depth report.
- Github repository.
- Risk dashboard.
Brief Overview of Model Architecture
Expand for Model Overview
Our model is encapsulated in the above schema.
Inputs
At initialization, we generate:
- A series of random (but realistic) prices using standard stochastic processes.
- Debt distributions (which represent loans) for each LLAMMA, sampled using a Gaussian Kernel Density Estimator trained on historical crvUSD data.
- Market liquidity, both within the Curve pools we simulate, and external sources such as Uniswap.
We define “scenarios” that determine the generative parameters of these three distributions. For example, the high volatility scenario will have higher volatility parameters for the GBM that generates collateral prices.
Modules
We then instantiate Python objects representing each of crvUSD’s contracts using the crvusdsim package built by 0xReviews, and the curvesim package built by the Curve research team. This includes the StableSwap and TriCrypto pools used by the oracles.
Agents
We then simulate three agents interacting with all of the above modules based on the simulated prices.
- The arbitrageur will arbitrage prices across all simulated pools (LLAMMAs, StableSwap, TriCrypto). This includes soft liquidations.
- The liquidator will perform any profitable hard liquidations against the Controllers.
- The keeper will update the Peg Keeper whenever possible.
Simulation
We run the simulations on a 24 hour horizon with 5-minute timesteps. We run 1000 simulations for each scenario in parallel and collect key metrics such as Bad Debt, Liquidated Debt, Peg Keeper Debt, etc… We then aggregate and store these results.
Overview of Results
We identified extreme collateral price volatility, stablecoin depegs, and fluctuations in crvUSD liquidity as the primary sources of risk. That said, we find that under reasonable market stress, the crvUSD system adequately incentivizes liquidators to close underwater positions and avoid potential insolvencies.
For all the results that follow, we categorize scenarios as baseline, adverse, or severe which correspond to increasing stress. For example, the severe volatility scenario has much higher volatility than the baseline volatility scenario. For exact numbers, please refer to §4.2 of the report.
crvUSD Liquidity
We simulate how liquidations perform as the amount of crvUSD liquidity accessible to liquidators decreases. Notice that this liquidity is largely concentrated in Curve’s Peg Keeper pools, which are also the price sources for crvUSD’s oracles. We have found that, if Curve fails to incentivize crvUSD deposits in Curve’s Peg Keeper pools, the resulting lack of liquidity may lead to missed liquidations as well as cascading liquidations (i.e., deflationary price spirals). We suggest the protocol should aim to maintain at least 20% of crvUSD debt in its Peg Keeper pools.
A failure-case occurs (for example) if a large portion of crvUSD debt is deposited in locked contracts, such as some lending pools, staking pools, or bridge contracts, where it no longer is accessible to liquidators. We discuss some strategies for incentivizing crvUSD liquidity in §6.2 of the report, such as diverting a portion of crvUSD borrower interest to further incentivize the PK pools if deemed necessary. A possible next step is to begin tracking this crvUSD debt to liquidity ratio on CurveMonitor.
Oracles and Chainlink Limits
crvUSD also uses special-purpose oracles that point to a small subset of high-TVL Curve pools and apply Exponential Moving Average (EMA) smoothing to minimize borrower losses due to transient price fluctuations. Under-the-hood, these pools are using USDC and USDT as proxies for the dollar, matching them against the USDC and USDT prices from the Peg Keeper tokens to discern a collateral/USD price. Our simulations have identified a few scenarios where these underlying Curve pools may exhibit price distortions that lead to missed or excessive liquidations.
The main reason these distortions may occur is if either USDC or USDT momentarily (or permanently) lose their peg. To address this concern, we consider re-instituting the oracles’ Chainlink limits in our simulations, which allow crvUSD’s oracles to default to Chainlink aggregator prices when their EMA prices deviate by a preset limit. We find that these limits could drastically mitigate borrower losses and liquidations in the event of a stablecoin depeg. Although, as shown in previous modeling efforts by the Curve team, such low Chainlink limits may lead to more borrower losses under normal volatility conditions.
LVR and Fees
Throughout our simulations, we also measure borrower losses from soft-liquidations. Using the LVR framework proposed by Milionis et al., we measure the Mark to Market (MTM) value extracted from LLAMMAs as they buy and sell assets at worse-than-market prices. We compare these LVR to the fees accrued by the LLAMMAs to estimate net borrower losses. We find that under moderate volatility regimes, high-leverage borrowers may suffer meaningful LVR that is not entirely offset by fee income, and which may lead to unnecessary liquidations. In the below image, we plot the percentage of LVR that was covered by fees for varying volatility regimes.
We simulate slight increases in LLAMMA’s fees to address this concern, such that fees may more closely offset expected LVR without dis-incentivizing arbitrageurs from re-balancing positions. At slightly higher fees (e.g. 0.9%), we observe a reduction in liquidations as compared to the current fees (0.6%), indicating that LVR might actually be causing a small portion of “unnecessary” liquidations. The protocol may experiment with slight fee increases on one of the crvUSD markets, and observe whether this leads to a reduction in borrower losses or a reduction in liquidations, while making sure it does not stall the soft-liquidation process. Of course, optimal fee setting is a deep area of AMM research and was not the primary focus of this risk model. More work should be done to discern optimal fees and their implications. Here we highlight that fees are a crucial parameter in balancing smooth soft-liquidations against excessive borrower losses, and play a key role in the protocol’s resilience to market risk.
Peg Keeper Risk
One concern regarding the Peg Keeper is that it may lead to a cascade in token prices. Taking the USDC Peg Keeper as an example, one can imagine that if USDC depegs, the Peg Keeper may mint excessive amounts of crvUSD to reclaim 1:1 parity between the two tokens. In the process, crvUSD gets unnecessarily devalued relative to the market. The PK’s debt ceiling and aggregator mechanism are meant to prevent this from happening.
In our “USDC depeg” simulations, approximately 1% of runs end with the USDC Peg Keeper having minted close to its debt ceiling (25M crvUSD), meaning that in 99% of simulations the Aggregator does a good job of blocking the USDC Peg Keeper from performing updates. We have found that the Aggregator only ever fails to block the USDC Peg Keeper when there is more liquidity in the USDC Peg Keeper pool than on all the other Peg Keeper pools combined (roughly, it’s slightly more complicated than that). This is an unlikely scenario, since a USDC depeg would likely lead to a rapid “flight to safety” from USDC to USDT, leading to a reduction in USDC liquidity. In short, the Aggregator mechanism, which largely relies on the reflexivity between USDC and USDT, is key in mitigating crvUSD’s exposure to each individual peg keeper token.
This indicates that a key goal of the DAO should be to onboard a diverse set of liquid Peg Keeper pools. In theory, these Peg Keeper tokens should not be highly-correlated in periods of extreme stress. That is, we would like to increase the amount of Peg Keeper tokens where, if one of these tokens (e.g. USDC) depegs, the other tokens will not depeg. The reflexivity between USDC and USDT is a great example, whereas the correlation between USDC and DAI is a counter-example and is not as desirable. Once such a token is onboarded to the Peg Keepers, it could then be included in the LLAMMA oracle feeds (similar to how USDC and USDT are included), which would require the creation (and possibly incentivization) of a new TriCrypto-ng pool. This would help stabilize oracle prices in the event of a stablecoin depeg.
Future Work
We see this as a significant step towards active and comprehensive risk management for crvUSD. Some possible extensions of this work are listed below.
- Extend the model’s parameter searches to other key parameters, including the loan and liquidation discounts (LTV parameters).
- Enhance the model to handle onboarding new markets to quantify the effect on protocol risk and set optimal parameters.
- Analyze the effect of onboarding new stablecoins to the Peg Keeping system in the event of a USDC or USDT depeg.
- Expand the scope of stress scenarios to handle network congestion.
- Improve model implementation to make the model faster and more accurate.
Conclusion
The primary contribution of this project is to develop a Curve-specific ABM for simulating the crvUSD protocol, and use it to identify key risks and how they may be mitigated. Through this investigative process, we hope to have de-mystified certain key mechanisms in the system and provided a useful framework for the Curve DAO to understand the crvUSD protocol from a market risk perspective.
All results are constrained by the modeling assumptions and limitations discussed in §7 of the report, as well as the scenario assumptions outlined in §4. It is worth noting that the crvUSD protocol is very intricate, and relies on a combination of several complex mechanisms, including novel AMMs, health calculations, and specialized oracles. A large part of this modeling effort was to investigate and understand these intricacies, incorporate them into a high-fidelity model, and describe them in simpler terms in our report. However, this complexity increases the probability of unknown unknowns that may pose a risk to the system and undermine the accuracy of our results.
Future work may involve applying the model to different market conditions and investigate the
impact of changing the protocol’s parameters, or modifying the logic of select smart contracts.
For example, the model may be applied to investigate the impact of deploying different Peg
Keeper and Oracle mechanisms.
Special thanks to @nagaking, @chanho, @WormholeOracle and @0xstan for feedback and help with implementation!