[MRC-46] Deposit Caps Methodology V2 (1st Run) and Suggested Caps Update

The objective of this post is to present the results of the first run of the dynamic deposit caps methodology V2, compare them to the current caps on Mars and offer some adjustment suggestions based on these results.

We’re looking into performing this exercise once every 1-3 months and present the results and recommendations to the community for further discussion.

As a reminder, the new methodology seeks to determine the deposit caps by scaling the current total supply of a collateral token up to the point where the probability of bad debt accrual in the protocol, estimated from a variety of price and liquidity scenarios, is extremely small. Specifically, we allow bad debt to occur in only 0.1% or 0.5% of severe stess scenarios. We consider daily price and liquidity scenarios based on both historical and simulated data. Bad debt is calculated by reevaluating accounts and running the liquidation mechanism at each point of the scenario grid. Liquidations are performed until the realized slippage remains below the liquidation bonus. The on-chain liquidity is only taken into account when determining the market depth at each instant. However, we assume that the on-chain price recovers to the off-chain level after a 1-hour recovery time.

Thus, the multiplier obtained in each framework run shows how many times it is possible to increase or decrease the current supply so that bad debt begins to accrue in the protocol under a certain price change scenario and a simulated accounts snapshot (each snapshot contains about 3K accounts). Multipliers are first determined for a set of simulated scenarios and accounts, and then the final multiplier is determined taking into account the scenario probabilities (probability distribution of the multiplier). The maximum multiplier for each run is capped at 20 (i.e., we consider that deposit caps cannot be increased by more than 20 times the current caps).

The algorithm consists of the following key steps:

  1. Deposit multipliers are determined for each token independently given fixed deposits for other tokens.
  2. Caps are determined for all tokens simultaneously assuming the same multiplier for all tokens.
  3. Minimum multiplier between steps 1 and 2 is taken for each token.*
  4. Steps 1-3 are repeated for a set of historical (stressed) and simulated (stressed) price scenarios. The multiplier is determined as 0.1% or 0.5% CVaR (or VaR) across all simulations.
  5. Final caps are determined by taking the minimum between ‘real-data’ caps and ‘simulated-data’ caps.
  6. To ensure conservatism of the updated caps, backtesting is run for both real and simulated price scenarios, i.e. the minimum bad debt across the scenario horizon is calculated under multiple scenarios.
  7. The resulting model caps are further restricted by applying maximum expert-based caps.

*Note. The procedure is not strictly automated. Expert adjustments may be needed in steps 1 and 2 while using the model. E.g. if the resulting individual deposit multipliers for some tokens are less than 1 (current deposit reduction is required), then they are fixed at the reduced (or current) level. Simultaneous search then continues to determine the multiplier for remaining tokens.

Note. If it is necessary to update the cap for a certain token, then step 2 is skipped; deposits for the remaining tokens are fixed at their current cap levels.

The sections below show the simulation results and caps suggested by the methodology.

Real-Data Scenarios
The deposit multipliers obtained for all tokens independently and simulateneously in each simulation are presented in the figures below.

The resulting caps obtained from a set of historical data scenarios are provided in the table below. The Real-Data Model Cap is the minimum between individual and simultaneous caps.


Simulated-Data Scenarios
Then the framework was run for a large number of simulated price scenarios. The parameters of the GARCH(1,1) model with multivariate Student-t distribution of noises were calibrated from historical data over the past year and during simulations the volatility of simulated returns has been increased by 20% to get really stressed trajectories.

The deposit multipliers obtained for all tokens independently and simulateneously in each simulation are presented in the figures below.

The resulting caps obtained from a set of simulated data scenarios are provided in the table below. The Simulated-Data Model Cap is the minimum between individual and simultaneous caps.

Final Suggested Model Caps
The resulting model caps obtained from a set of real and simulated data scenarios are provided in the following table. The Model Cap is the minimum between real-data and simulated data caps.


Suggested Caps
The resulting model caps are further restricted by expert-based maximum allowable values to ensure conservatism. The following table summarizes the final suggested maximum caps obtained in accordance with the methodology:

Note that in the table above, the Final Suggested Max. Cap is the minimum between the Model Cap, which represents the cap according to the simulation methodology, and the limits determined by onchain circulating supply and offchain depth.

The backtetsing results for the resulting caps are provided in the Appendix.

The following table compares the caps suggested by the methodology against the current caps (including both the Red Bank and Farm):

Based on the obtained results and the current level of utilization of the different markets within the Red Bank and Farm, we propose to increase the following caps:

Red Bank:

axlUSDC from 3M to 3.5M axlUSDC.

While this is a modest increase, we believe it makes sense given that the current utilization level is at 80% (not full). At 3.5M, there would be an additional 1M in supply capacity in this market.


axlUSDC/OSMO from 750K to 1.5M axlUSDC.

Edit (18/09/2023): Additional Cap Suggestions

Red Bank:

  • stATOM from 200,000 stATOM to 350,000 stATOM.


  • stATOM/ATOM from $3M axlUSDC to $1M axlUSDC.


This is a signaling proposal, not an executable proposal.

The Mars smart contracts on the Osmosis chain are currently controlled by the Builder Multisig address. If this proposal passes, the builders will utilize their multisig to make the necessary parameter changes.

Appendix. Backtesting Results
To ensure conservatism, the resulting caps have been run through the simulation framework and the minimum bad debt across the scenario horizon was recorded in each simulation. The resulting bad debt dollar value is provided in the figures below.

Historical Scenarios (stressed), 25K runs:

Simulated Scenarios (stressed), 100K runs:

The maximum bad debt observed over all simulated scenarios was about $60K (~0.2% of the $32M TVL).

If I may make a suggestion before this proposal goes live, let’s increase the stATOM Red Bank cap as well.

Late this week, the liquid staking module went live live, leading to a large amount of stATOM being minted. As a result, the stATOM cap on Mars has been maxxed out. stATOM deposits on Umee have also seen a substantial jump since LSM went live.

Since the Mars Deposit Cap Methodology supports it, I suggest we increase the stATOM cap on Red Bank from 200K → 225K. This would still be less than the suggested max cap from the Methodology.

@tatiana, @JonathanE

1 Like

Good suggestion! I think we could even do the following, which would further increase stATOM capacity on Mars:

  1. Reduce the stATOM/ATOM cap to $1M axlUSDC, since its utilization has significantly decreased since concentrated liquidity went live.
  2. Increase the stATOM cap on the Red Bank from 200,000 to 350,000 stATOM.

This would allow the overall cap to be within the suggested maximum level while at the same time increasing capacity where it’s needed the most.

I’m going to proceed to edit the above proposal to reflect this.

1 Like