Hey everyone, I’m Tatiana, from Delphi Labs. The following sections cover a proposed framework we developed to set the deposit caps for the Red Bank and Rover. If the general response to the framework is positive, its ratification by the DAO could be put up for a vote in the upcoming weeks.
A comparison between the current caps and the caps recommended by this framework will be published at a later date to complement this post.
1. Introduction
The deposit cap determines the maximum amount of a token that can be supplied to the protocol and, therefore, how much of it can be used as collateral. An excess concentration of a certain token in the protocol relative to its circulating on-chain liquidity increases its exposure to liquidity risk and vulnerability of the protocol to price manipulation, so limits are placed on the total amount that can be supplied to the protocol to prevent potential insolvency issues.
Following the general idea of determining caps proposed by Chaos Labs [1] for AAVE, we implemented a simplified static simulation framework for setting a supply cap for each collateral token in terms of liquidity risk, i.e., the inability to liquidate part of the supply at a price favorable to liquidators.
As the supply of the token in the protocol grows, so does the debt collateralized by that token. When the price of collateral drops significantly due to severe stress events, the amount of collateral that needs to be liquidated in exchange for a debt token also increases. A liquidation of high volume leads to a large price slippage on DEXes, whereby the liquidation could become unprofitable for liquidators, resulting in a bad debt accrual for the protocol. In order to minimize the risk of the protocol becoming insolvent, the supply cap can be defined in such a way that during times of stress liquidation would be successful, assuming healthy and rational liquidator activity.
The methodology defines a supply cap for a given token at which the maximum collateral amount eligible for liquidation calculated over a set of potential price change scenarios, doesn’t exceed the amount that can be liquidated profitably, i.e., keeping a realized price slippage below the liquidation bonus.
The document is organized as follows. A general description of the methodology is given in Section 2. Section 3 is devoted to the account simulation algorithm. Sections 4 and 5 detail how the maximum liquidatable amount and market liquidity are determined, respectively. Section 6 specifies the maximum caps. Final caps and discussion of the results are given in Section 7.
2. General Methodology
This section describes the overall methodology design, the individual components are discussed in more detail in subsequent sections.
Definitions:
- Current Supply – current dollar amount of the token supply in the protocol.
- Maximum Liquidatable Amount – the maximum dollar amount of token eligible for liquidation obtained throughout simulations.
- Maximum Amount Liquidated – the maximum dollar amount of token that can be liquidated with slippage below the liquidation bonus.
- x% Depth – the market liquidity, dollar cost to move the on-chain price down by x%.
Framework:
For each collateral token, the amount eligible for liquidation (LiquidatableAmount) is first determined for the protocol when prices change in accordance to a given scenario.
To account for variability in the distribution of total supply and borrowing across accounts due to changes in user behavior, the allocation of collateral and borrowed funds across accounts is simulated based on current real data (a snapshot of accounts as of the reference date). A detailed description of the simulation algorithm is given in Section 3. Historical 10-day price change scenarios are used over the past year (for details, see Section 4).
The maximum for all price change scenarios and simulated protocol states is taken to derive MaxLiquidatableAmount. It is assumed that all amounts are liquidated at once.
Assuming also that all supply serves as collateral, a maximum portion of the total current supply that must be liquidated is defined as follows:
Liquidation Ratio = MaxLiquidatableAmount / CurrentSupply
Assuming the same portion of collateral is under liquidation when supply rises to the SupplyCap level, we obtain the amount of collateral eligible for liquidation:
MaxLiquidatableAmountNew = Liquidation Ratio * SupplyCap
As mentioned in the introduction, the main idea behind determining the supply cap is that the maximum liquidatable amount doesn’t exceed the amount that can be liquidated profitably. A liquidation is considered profitable when a realized slippage is below a liquidation bonus. Thus, the amount that can be liquidated profitably is determined by the market depth of the liquidation bonus level, which represents a cost of moving price down by the liquidation bonus. The liquidation bonus depends on the collateral token, however in this methodology a minimum 5% bonus is conservatively used for simplicity. So, the amount that can be liquidated profitably is simply equal to 5% market depth:
MaxAmountLiquidated = Depth_5pct
Note that the extreme depth is used here as the market liquidity tends to disappear at times of stress. The on-chain liquidity is only taken into account when determining the depth. The input data used and the procedure for calculating the stressed 5% market depth are detailed in Section 5.
Note. Under a less conservative approach, bad debt tolerance can be additionally incorporated. In that case, the amount of collateral that can be covered by the insurance fund (beyond what can be liquidated profitably) should be added to the market depth.
Assuming zero bad debt tolerance, the supply cap is finally determined from the condition that the extreme liquidatable amount under the extended supply equals to the maximum amount that can be liquidated profitably at once:
MaxLiquidatableAmountNew = MaxAmountLiquidated
from which we have:
SupplyCap = CurrentSupply × Depth_5pct / MaxLiquidatableAmount
The ratio Depth_5pct / MaxLiquidatableAmount shows how many times MaxLiquidatableAmount can be liquidated profitably given all amount is liquidated at once.
The resulting model caps are further restricted by applying maximum expert-based caps described in Section 6. The final supply caps obtained in accordance with the proposed methodology are provided in Section 7.
The key methodology assumptions and limitations are summarized below:
Assumptions:
- All supply serves as collateral.
- Additional supply and borrow amounts will be distributed similarly to the current supply and borrowing activity. The distribution of the health factor of accounts in the protocol will remain similar as the supply and borrow grows. Consequently, with an increased supply, the portion of the liquidated collateral remains essentially unchanged.
- To model price change scenarios, a 10-day risk horizon is used.
- The worst liquidatable amount is taken over a set of historical scenarios and simulated collateral and borrowing allocations across accounts.
Limitations:
- All collateral eligible for liquidation is liquidated at once. The dynamic impact on the price and liquidity recovery (due to arbitrage) is not simulated.
- The on-chain liquidity is only taken into account to determine the market depth.
- A fixed liquidation bonus is used, regardless of the collateral type and HF of the position.
- Zero bad debt tolerance is considered.
The above assumptions and limitations are as conservative as possible due to high uncertainty in user behavior, price and liquidity dynamics. Some of them may be revised and relaxed in the future.
3. Account Simulation Framework
When simulating accounts, the following key components can be distinguished in the modeling algorithm:
- Supply distribution across accounts per token
- Borrowing distribution across accounts per token
- Health Factor (HF) distribution for accounts
Accounts can be simulated in different ways depending on the input data, distribution assumptions and restrictions on parameters that must be met. Namely, some of these parameters should be fixed, while others can vary during simulation: the number of accounts, total borrow and/or total supply per token, HF distribution, borrow/supply amount distribution across accounts, total collateral size for the account, share of accounts with no borrowed funds, etc.
When simulating token amounts and HF for each account, different distribution types can be considered:
- Empirical distribution
- Parametric distribution fitted to a real data
- Given parametric distribution with user-specified parameters
The choice of approach can be determined by the goals of the modeling exercise. The empirical distribution and the parametric distribution fitted to real data are closest to the current real state of the protocol. Therefore, when assessing risks for fairly short-term horizons, it is reasonable to rely on the current distribution.
In the long run, the distribution can change significantly over time. In this case, a set of theoretical distributions with arbitrary parameters allows for greater diversity in accounts simulation by specifying various phenomena of user behavior.
Our framework uses the empirical distributions that correspond to a current protocol state as of the calculation date and are not expected to change significantly in the near future. It is also assumed that these distributions will remain the same with an increase in the total supply of a given token in the protocol.
The accounts are simulated as described below.
Input parameters. The following parameters are assumed to be fixed: number of accounts, total supply, and total borrow amounts per token. These parameters, as well as the actual distributions of tokens’ amounts and HF, are taken from the protocol as of the reference date (snapshot of all accounts).
Supply distribution. For each account and for each collateral token, the collateral amount is first simulated from a real empirical distribution of collateral amounts for this particular token. The resulting amounts are then normalized so that the amount summed across all accounts equals to a total token’s supply.
For each account, the risk-weighted collateral value is determined by using the current token prices and liquidation thresholds determined in accordance with the general Mars Risk Framework [3].
Health Factor distribution. The account’s Health Factor is simulated from a real empirical distribution of health factors obtained from the protocol. Only health factors of accounts that have borrowed funds are used to get the empirical distribution. So, initially it’s assumed that all accounts have borrowed funds (this assumption is eliminated further).
Borrowing distribution. Based on the simulated risk-weighted collateral value and HF, the total debt value is calculated for each account which is required to reach the simulated HF. The calculated debt values must be broken down by types of tokens and updated so that the total value of borrowed funds across accounts is equal to a given total borrow for each token.
In order to split the user’s debt into tokens, the weights of tokens are simulated randomly for each account. Here, for a greater diversity of simulated accounts, the weights are simulated from a uniform distribution, without fixing the distribution of borrowed funds across accounts. The distribution of borrowed funds between accounts is carried out successively in such a way that the total amount is equal to the amount of borrowed funds of the protocol. If during the generation of weights, it turns out that for a certain token the cumulative value of borrowed funds has already reached the total value for the protocol, then the weights are redistributed among the remaining tokens. The procedure is repeated until all borrowed funds are distributed among the accounts.
Since the protocol is strongly over-collateralized, in most cases, as soon as the procedure is complete, there are accounts that have zero debts, which corresponds to reality, since originally there are a lot of purely deposit accounts in the protocol. In very rare cases, it could happen that there are undistributed borrow amounts for some tokens. In that case the remaining amounts are distributed proportionally to the total free collateral (collateral minus debt) among all accounts.
These re-allocation procedures are necessary to ensure that the amounts of borrowings were equal to the given values and may lead to some minor changes of the resulting empirical distributions in comparison to the original ones.
An example of simulated and actual HF distributions is provided in the figure below:
As seen, the empirical distribution is quite similar to the original one. Note that zero HF means that there are no borrowed funds in the account.
4. Max Liquidatable Amount
The amount of total supply of each token subject to liquidation across simulated accounts is calculated by using a set of price change scenarios.
In practice, the following approaches to generating price scenarios are usually used:
- Apply a fixed stress scenario bump to the price of a given token (e.g. -15% for stablecoins and -50% for others) assuming prices of other tokens remain unchanged.
- Use historical price movement scenarios over the period covering severe market stresses.
- Simulate price trajectories in accordance with a given mathematical model, e.g. Brownian motion, GARCH-type family of models, copula-based models etc.
- Use historical price change patterns of crashed tokens.
In order to capture actual linear and non-linear dependencies between token prices, the historical 10-day overlapping price returns are used over the past year. The horizon is chosen for conservative reasons.
We then run 10,000 account simulations. For each simulation and for each price change scenario, we calculate the amount to be liquidated for each token. In each scenario, the amount to be liquidated is calculated per token as the sum across all accounts for which the HF went below 1 due to price changes.
The maximum across all scenarios and simulations is taken as the final liquidation amount for each token.
5. Max Amount Liquidated
This section describes how the collateral amount that can be liquidated profitably is determined. A liquidation is considered profitable for a liquidator if it results in a price slippage below the liquidation bonus. Transaction fees are omitted here.
The liquidation bonus depends on the collateral (and HF), however here for simplicity we conservatively use a minimum liquidation bonus of 5% for all collateral tokens. Essentially, the amount that can be sold profitably is determined by the -5% market depth (cost to move price down by 5%).
The liquidity of each token can be divided into off-chain and on-chain liquidity. Here we define off-chain liquidity as all the liquidity that’s not on the chain itself. For instance, if we’re considering an asset on Osmosis, the off-chain liquidity would be all the liquidity on CEXs and on other chains (including other Cosmos chains, Ethereum, etc.).
These types of liquidity can affect each other through arbitrage activities. When off-chain liquidity is exhausted, it can be expected that after some time arbitrageurs will bring back the pool to its initial state. When the pool is arbitraged back, liquidations can continue at their previous, limited pace. While there’s no arbitrage, liquidations will probably stop until the pool is arbitraged back.
The dynamics of liquidity in times of stress is the subject of a separate study and requires the identification and investigation of real case studies. In order to be conservative, this methodology only considers on-chain liquidity.
To calculate on-chain depth, historical daily liquidity data is downloaded from Osmosis Imperator for all pools. Only two asset pools are considered. Then for each collateral token we do the following:
- The subset of pools is selected containing this token
- The depth is calculated for each pool according to the bonding curve type for that pool (xyk or stableswap)
- Depth is aggregated across all pools from the subset
Note. Summing up liquidity across all pools to get liquidity of a collateral token is not exactly an accurate approach, since it is necessary to take into account the liquidity of the collateral-debt token pair, i.e., all possible routes in which a collateral token can be exchanged for a debt token. For instance, let the liquidator need to swap USDC collateral for XYZ debt (to repay a flash loan). There are several routes the liquidator could use: a) swapping it all in the XYZ/USDC pool (if it exists), b) swapping XYZ for ABC in the XYZ / ABC pool and then ABC for USDC in the ABC/USDC pool, c) a combination of the 2 above, d) any other combinations based on all the pools available. In this framework, we consider that the total liquidity across all pools is an acceptable proxy.
The 5% depth is calculated as a token amount that can lead to a price slippage of 5%. The price slippage is determined as follows:
Slippage ≡ (EffectivePrice / PreSwapSpotPrice - 1) * 100%
where EffectivePrice = ∆x / ∆y is the (average) execution price for the liquidator, ∆x is the amount of token sold (it is a desired pool depth), ∆y is the amount of token received, Pre-Swap Spot Price is the spot price before liquidation. Equating slippage to a given value (5%) and solving it for ∆x, we derive the desired 5% depth at each point in time.Preformatted text
For the xyk pool (xy=k) we obtain:
Depth_5pct = 5% * CollateralTokenReserve
For the stableswap pool (Solidly stableswap curve: xy(x^2+y^2)=k) the depth is calculated using the numerical root finding algorithm.
It is clear that the depth varies from day to day, and in times of stress liquidity outflow could significantly reduce the market depth. Hence, a shock is applied to the current depth level to get the stressed one:
StressedDepth_5pct = CurrentDepth_5pct * (1 - Shock)
where Shock is calculated as 95% daily historical simulation Value-at-Risk, i.e., a relative daily change in depth that can be breached in 5% of historical scenarios within a 1-day horizon.
6. Max Caps
The resulting model caps are restricted by maximum allowable values to ensure conservatism. The maximum cap for each collateral token is determined as follows:
MaxCap = min(MedianOnChainDepth_25pct_90d, 10 * Global Depth_2pct)
where:
MedianOnChainDepth_25pct_90dis the dollar cost required to move the on-chain price down by 25%. The 25% on-chain depth at each historical time instant is determined as described above, then the median value over the last 90 days is taken.Global Depth_2pctis the total dollar liquidity required to move the price by -2%, aggregated across key centralized and decentralized exchanges (top 10 exchanges according to a Coingecko ranking, as well as Osmosis, Uniswap V2 and V3, and Sushiswap). Depth values are taken from Coingecko as of the reference date.
Thus, the final cap is obtained by taking the minimum between the model and maximum caps.
7. Numerical Example
Let’s apply the proposed methodology to determine the OSMO deposit cap. We have the following inputs:
CurrentSupply = $4,278,025
Depth_5pct = $2,465,863
MaxLiquidatableAmount = $403,776
MedianOnChainDepth_25pct_90d = $18,373,852
GlobalDepth_2pct * 10 = $15,664,002
The maximum cap is obtained as follows:
MaxCap = min(MedianOnChainDepth_25pct_90d, GlobalDepth_2pct * 10) = $15,664,002
The model cap is obtained as follows:
ModelCap = CurrentSupply * Depth_5pct / MaxLiquidatableAmount = $4,278,025 * $2,465,863 / $403,776 = $26,125,931
The final cap equals to:
FinalCap = min(ModelCap, MaxCap) = min($26,125,931; $15,664,002) = $15,664,002
Conclusion
In the previous sections we covered our proposed framework to determine the caps for the Red Bank and Rover. As mentioned, these caps are a fundamental risk mitigation tool for the protocol. Ideally, the deposit caps should be monitored and updated with a certain frequency.
Note that the model caps are obtained under a stress scenario approach, making the most conservative choices at each stage of the methodology due to the high level of uncertainty in user
behaviour, price and liquidity dynamics. Specifically, we use the worst historical price change scenarios over the past 1 year to get the liquidatable amount. A risk horizon of 10 days (i.e. 10-day price changes) is considered. The worst simulation is selected over all generated ones. The on-chain liquidity is only considered to get the amount that can be liquidated profitably. A minimum liquidation bonus of 5% and stressed market depth are used. The parameters mentioned above and the underlying assumptions are to be reviewed regularly.
Further development of the methodology can be aimed at performing dynamic simulations, in particular, introducing price and liquidity trajectories into the model, taking into account partial or complete recovery of liquidity after a certain time delay, simulating liquidation bots with a dynamic liquidation bonus and close factor, and modeling temporary and permanent price market impact.
Copyright
Copyright and related rights waived via CC0.
Disclaimers/Disclosures
This proposal is being made by Delphi Labs Ltd., a British Virgin Islands limited company. Delphi Labs engages in incubation, investment, research and development relevant to multiple ecosystems and protocols, including the Mars Protocol. Delphi Labs and certain of its service providers and equity holders own MARS tokens and have financial interests related to this proposal. Additionally, Delphi Labs is one of several entities associated with one another under the “Delphi Digital” brand. Delphi Digital’s associated entities and/or equityholders or service providers of such entities may hold MARS and may have financial interests related to this proposal. All such entities, service providers, equity holders and other related persons may also have financial interests in complementary or competing projects or ecosystems, entities or tokens, including Osmosis/OSMO. These statements are intended to disclose relevant facts and to help identify potential conflicts of interest, and should not be misconstrued as a complete description of all relevant interests or conflicts of interests; nor should they be construed as a recommendation to purchase or acquire any token or security.
This proposal is also subject to and qualified by the Mars Disclaimers/Disclosures. Delphi Labs may lack access to all relevant facts or may have failed to give appropriate weighting to available facts. Delphi Labs is not making any representation, warranty or guarantee regarding the accuracy or completeness of the statements herein, and Delphi Labs shall have no liability in the event of losses or damages ensuing from approval or rejection or other handling of the proposal. Each user and voter should undertake their own research and make their own independent interpretation and analysis of all relevant facts and issues to arrive at their own personal determinations of how to vote on the proposal.
References
[1] Chaos Labs Updated Supply and Borrow Cap Methodology: Chaos Labs Updated Supply and Borrow Cap Methodology - Risk - Aave
[2] Mars Risk Framework: mips/Mars-Risk-Framework.md at main · mars-protocol/mips · GitHub