Warden Finance Risk Methodology
We’ve recently published our roadmap for Q2 2023. Through this roadmap, we have committed to doing assessments of periodic risk parameter updates for Moonwell Artemis and Apollo protocols.
We are now sharing the framework we’ll be using to test out the robustness of the proposed parameters. Moonwell Artemis and Apollo risk methodology is now available through our documentation.
This forum post aims to communicate the key points of this methodology to the Moonwell community and gather feedback. As always, let us know if you have any questions.
Risk Vectors
The Moonwell protocol is subject to multiple risks:
- Economic risks (i.e Volatility, liquidity, oracles)
- Technological risks (i.e Smart contracts, chain availability, bridges)
- Governance risks (i.e Voting power)
The proposed methodology focuses on mitigating the following economic risk vectors: volatility, liquidity and oracle risk.
Volatility Risk
As collateral and debt asset prices change, the collateralization of accounts changes. In order to maintain solvency, the protocol must ensure that debts are always overcollateralized by assets of a higher value. Otherwise, borrowers would be economically incentivized to default on their debt. This would lead to the creation of bad debts in the system. In order to mitigate asset volatility risk, the protocol enforces liquidations to ensure that debts are always overcollateralized.
Liquidity Risk
If an account collateral ratio breaches the minimum collateral ratio enforced by the protocol it will become eligible for liquidation. In order for liquidators to be able to liquidate assets at a reasonable price there must be sufficient on-chain liquidity for liquidators to liquidate accounts profitably. If an account can’t be liquidated successfully because liquidity is constrained, the protocol won’t be able to effectively mitigate its exposure to a given asset’s price volatility.
The protocol is also subject to market liquidity risks since mTokens used as collateral need to be redeemed when a flash liquidation occurs. In order for mTokens to be redeemed to underlying Moonwell markets must be sufficiently liquid (i.e. utilization has to be below 100%).
Oracle Risk
Moonwell relies on Chainlink oracles to determine solvability of accounts. By design, the oracle price lags the actual market price, and also may not exactly track the actual spot price on decentralized exchanges of a given chain.
If oracle prices are not in line with on-chain prices, users could borrow more than they have deposited leading to bad debt. More importantly, oracle prices must remain in line with market prices in order for liquidators to be able to profitably liquidate risky accounts. For example, if the oracle price of an account’s collateral asset is lower than its market price it could make a liquidation unprofitable.
Methodology
Interest Rate Model
When reviewing interest rate model parameters, our objective is to optimize their utility and reserve generation potential, while also mitigating liquidity risks.
In an optimal scenario, utilization should be as close to the kink utilization in order to maximize yield for lenders and fees for the protocol. In order to keep utilization as close to kink as possible, multiple factors should be taken into account:
- Current and historical market utilization
- Rewards, borrow and lend side, if applicable
- Intrinsic yield of asset (i.e wstETH vs ETH), if applicable
- Comparison with similar markets
- The asset’s borrow cap
In order to manage liquidity risk, economical risk factors of underlying asset need to be considered:
- Redemption risk
- Volatility
- Liquidity / slippage
- Concentration
Methodology for assessing each parameter specifically is available on our documentation.
Liquidation Incentive
In order to validate the robustness of the liquidation incentive our methodology relies on backtesting the profitability of simulated liquidations given historical market conditions.
More specifically, we backtest the block per block profitability of liquidating a given amount of a collateral asset. Our backtesting simulation will look at historical oracle price skews, slippage, and gas costs.
Based on our backtesting simulation, we will assess the longest time it would have taken for a liquidator to profitably execute a liquidation of a given trade size. This worst time to liquidation metric will allow us to measure the robustness of liquidation discounts.
The liquidation discount should be set to a level that, given the worst historical downturn events, would have allowed a position of a determined worst case size to be liquidated profitably within a specified time limit.
The worst case trade size can be determined using the current largest borrow positions. For example, a case where the top 5 debt positions become liquidatable could be considered as the worst case trade size.
The liquidation time limit can be set to a fixed value of 60 minutes. The collateral factor will need to be able to at least withstand the historical max drawdown for this time period and also cover for the liquidation discount.
Collateral Factor
Our approach to set collateral factors goes hand in hand with our methodology for setting the liquidation discount.
In order to validate the robustness of collateral factors, our methodology looks at historical maximum drawdowns over a given period of time. The selected period of time has to be larger than the worst time to liquidation metric we computed when validating liquidation discounts.
Collateral factors should be set to a level that, given the worst historical downturn events, would have allowed a position of a determined worst case size to be liquidated profitably within a specified time limit.
Borrow Cap
We’ll determine the borrow cap setting using the max trade size for a determined threshold for buy-side slippage.
For example, a threshold of 5% buy-side slippage could be used for every asset.
Governance Parameters Test Cases
Every two weeks after Gauntlet’s parameter update, we’ll run the following tests to validate the robustness of the Moonwell’s governance parameters. We’ll also run 3 price changes scenarios based on historical VaR to identify key risks in the system.
| Test | Methodology | Actionable items |
| Interest Rate Model | ||
| 1.1 Market utilization is optimal | For every market, given normal market conditions, validate that utilization is equal or below the kink.
1. If utilization is greater than kink, explore the following factors:
|
Cause of sub-optimal market utilization is often multifactorial. Best way to address the issue differs on a case by case basis.
Here’s a list of possible actions:
|
| Rewards Rates | ||
| 2.1 Rewards incentivize desired behaviors | Validate that rewards are being distributed to markets that are relevant.
|
Adjust supply and/or borrow reward rates. |
| Reserve Factor | ||
| 3.1 Lending / borrowing rates are competitive | Compare lending rate, borrowing rate, utilization and market size with comparable markets (i.e USDT vs other stablecoins).
Make sure equivalent markets are in line with each other in risk / reward terms. |
Reduce or increase the reserve factor to match comparable markets |
| 3.2 Protocol reserves are sufficient to protect protocol against bad debt | Volatile and illiquid markets should have higher reserve factors than stable markets to compensate the DAO for the additional risks. | Adjust reserve factors. |
| Close Factor | ||
| 4.1 Small liquidations can be successfully executed | For every market, validate that a 100$ liquidation can be profitably executed given:
|
Increase the close factor up until liquidation can be processed profitably. |
| Liquidation Discount | ||
| 5.1 Worst case historical liquidation scenario can be executed profitably in under 60 min for all markets. | For every market, validate that the worst time to liquidation is lower than 60 min by running a liquidation backtesting simulation.
Liquidation backtesting input parameters:
|
Increase liquidation discount so that liquidation can be processed in less than 60 min. If the worst time to liquidation for a given asset is far superior than others, review the asset’s collateral factor. |
| Collateral Factor | ||
| 6.1 The collateral factor gives the protocol sufficient room to wait for 60 min to execute a liquidations profitably without incurring bad debts even if the collateral assets decrease by the max drawdown | For every concerned market, validate that (1 - collateral ratio) covers the sum of following values at minimum:
|
Decrease proposed collateral factor to cover total liquidation cost |
| 6.2 Parameter change doesn’t make any account liquidatable | Validate no account is liquidatable by running a collateral at risk simulation with following inputs:
|
Increase proposed collateral factor to avoid liquidations |
| 6.3 Parameter change doesn’t make any account liquidatable (on-chain) | On a local network fork, get the current liquidity for all accounts, then run the following simulation to evaluate system state after proposal is applied:
Simulation #1
|
Increase proposed collateral factor to avoid liquidations.
Reach out to the community to inform them to close their borrow positions. |
| 6.4. Parameter changes do not increase market risk exposure beyond desired level | Run Collateral at risk simulations with and without proposed parameter changes for the following scenarios:
|
Increase proposed collateral factor to maintain risk exposure within tolerance |
| Borrow Cap | ||
| 7.1. Protocol short exposure to underlying assets is manageable | For every market, test the following
|
Decrease the borrow cap liquidity and slippage to buy the asset has materially deteriorated. |