[0IP-2] LTV Risk Parameter Changes

Proposal

We propose adjusting LTV risk parameters for MATIC, WBTC, DAI, MAI, and MaticX on 0VIX Protocol.

Motivation

Updating the parameters seeks to maintain the overall risk tolerance of the protocol while overall boosting capital efficiency. We believe this proposal represents a healthy risk trade-off between specific assets that will make 0VIX more competitive in the Polygon ecosystem.

As shown in the figure above (extracted from our internal research simulations), subject to the current 10% liquidation incentives employed by 0VIX, the liquidation LTV for MATIC can be theoretically increased above 80% before incurring a larger than 1% risk of generating insolvent users on the protocol. We believe that a parameter update to 75% is conservative enough to guarantee healthy operations.

A similar argument can be made for wBTC. While the asset still carries theoretical structural risks due to the token being a bridged derivative product whose underlying is custodially held by BitGo, these risks cannot be mediated by LTV parameter tuning and would require delisting the asset altogether. We believe these structural risks are effectively ‘priced in’ by DeFi users and, as such, continue trusting the long-standing stability of the asset in leading us to increase its protocol parameter.

The reasoning behind DAI / MAI / MaticX is of a different nature as it requires a specific kind of risk assessment explicitly tailored to stablecoin assets (MaticX can be thought of as a MATIC-stable asset). The risks associated with these assets cannot be modelled via simple price stressing as their greatest risk is structurally associated with the chances that they depeg from their underlying. For these assets, we focus on the net depeg tolerance that the protocol can handle. The explicit calculation is complex and requires dynamic real-time updating as it generally requires analyzing both available DEX/AMM liquidity as well as usage of these assets as collateral on other Polygon lending protocols. However, as a general rule of thumb, the difference between 100% and the sum of liquidation LTV and liquidation incentive (10%) gives a rough estimate of the magnitude of depeg event which risks making 0VIX insolvent. For our stable assets, these depeg tolerances come out to:

  • USDC / USDT: 10%
  • DAI: 20%
  • MAI: 25%
  • MaticX: 30%

The main depeg risk for MaticX would result from a slashing penalty incurred by its validators. Given the extensive validator set offered by the Stader labs product, a majority of validators would need to be slashed throughout a 3-day epoch for a sufficient depeg event to take place. Given the permissioned and centralized nature of Polygon validators we deem this to be a low-probability event as it would amount to a structural failure of the Polygon blockchain as a whole and, as such, should be implicitly priced-in by a DeFi user engaging with our protocol.

The main depeg risk for MAI would be triggered by a sudden loss in value (>25%) of the reserve assets underwriting the MAI minting process. Given the vast diversification of these assets, we also deem this to be a low-probability event.

The main depeg risk for DAI is intrinsically connected to its underwritten USDC dependence. This topic has recently come under the spotlight following the OFAC sanctioning of Tornado Cash. These plus the implicit derivative-like nature of the DAI minting process make the asset inherently riskier than USDC. In this circumstance, we value the long-standing rigor of the MakerDAO process and trust in their capacity to ferry through the current macro-troubled waters. A regulatory attack on USDC would first and foremost affect USDC users (crashing the entire DeFi market) before DAI. As such, very similarly to our analysis for wBTC, we must assume that these structural risks are priced in by DeFi users since they cannot really be mediated via LTV tuning vs removal of the asset market altogether.

Details

We propose to update the LTVs on 0VIX as shown in this table.

Asset Current LTV Proposed LTV
MATIC 60% 75%
WETH 75% 75% (no change)
USDC 80% 80% (no change)
WBTC 70% 75%
USDT 80% 80% (no change)
DAI 60% 70%
MAI 50% 65%
MATIC X 50% 60%

Quorum Standards

The options with the most votes will be adopted.

Voting period:

  • 2 days

Vote options

Vote a) Increase MATIC LTV from 60% to 75%

  • Accept the proposal
  • Further discussion needed

0 voters

Vote b) Increase WBTC LTV from 70% to 75%

  • Accept the proposal
  • Further discussion needed

0 voters

Vote c) Increase DAI LTV from 60% to 70%

  • Accept the proposal
  • Further discussion needed

0 voters

Vote d) Increase MAI LTV from 50% to 65%

  • Accept the proposal
  • Further discussion needed

0 voters

Vote e) Increase MATIC X LTV from 50% to 60%

  • Accept the proposal
  • Further discussion needed

0 voters

Milestones and Deliverables

Once the community has voted the 0VIX team will implement the relevant changes in the following epoch as per the results of the voting.

4 Likes

Voted. Thank you. Another interesting proposal.

Love this! great proposal imo

Can I ask what is the standard parameters for testing LTV collateral ratios? Are you taking into account what the on-chain liquidity looks like because while 0VIX has a smaller pools, overall my guess is that if liquidations were to occur, they would occur in a similar manner across all lending pools (e.g. most people are probably taking on the same risk either at 0VIX or AAVE), so in that regard, has there been enough testing done to ensure that there’s enough on-chain liquidity in the event of a liquidation that there wouldn’t be any net losses to the protocol?

The first step is that any new asset added to the protocol will undergo rigorous cross-asset undercollateralization risk assessments to evaluate its ideal protocol parameters. Then as you already explained we also check for the on-chain liquidity available to liquidate all actively collateralised loans w/o suffering too much slippage. We’re calling it the ‘Toxicity Number’.

We explained this concept some months ago in a talk at a conference and how it should’ve prevented the whole stETH-ETH depeg situation which nearly crashed the space. As of now we’re testing this manually but this is a DeFi-wide metric so it doesn’t make sense for us to be the only one using it. We’re already working on oraclelising this metric so everyone benefits from it.

Then we also have a technical checklist that we go through that looks like e.g. check ‘mint’ rules on the smart contract level.

1 Like