Adaptive LTVs

The information provided by Aloe Labs, Inc. (“we,” “us” or “our”) on docs.aloe.capital (the “Site”) is for general informational purposes only. All information on the Site is provided in good faith, however we make no representation or warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of any information on the Site.

Under no circumstance shall we have any liability to you for any loss or damage of any kind incurred as a result of the use of the site or reliance on any information provided on the site. Your use of the site and your reliance on any information on the site is solely at your own risk.

Introduction

Aloe II is an overcollateralized money market. This means that if you post $1000 of collateral, the most you'd be able to borrow & withdraw is $900. If you divide {maximum allowed borrows} by {amount of collateral}, you get the loan-to-value ratio (LTV)－in this case 90%.

Other protocols manually specify LTVs (or "collateral factors") for each supported asset. Popular stablecoins like USDC tend to have high LTVs (90%+) while long-tail assets and memecoins receive lower LTVs－or aren't supported at all.

Aloe is different. It's designed to work without governance, so there's nobody around to manually specify LTVs. Even if there were, they'd have a hard time: any Uniswap position can be used as collateral, and since each one is unique, governance would need to select and vote on millions of different LTVs.

We had to come up with something new.

Goal

There's a tradeoff when selecting LTV. The higher it is, the more efficient the protocol－you can do more with the same amount of money. The lower it is, the safer the protocol－sudden spikes/drops in price are less likely to create bad debt. Therefore, for protocol designers and governance, the question becomes "How low must LTV be to create an acceptable level of risk for the target user?"

The key thing to realize is that LTV is related to the size and likelihood of sudden price movement. For example, say token XYZ plummeted 15% in an hour on its worst day ever. If XYZ's LTV were 85%, liquidators could begin closing positions at the top of that hour. Assuming the price moved linearly, they'd have about 40 minutes to liquidate the account and claim their full 5% liquidation incentive. After that, the incentive would decrease until reaching 0 at the end of the hour, resulting in bad debt.

Consider: -15%/hour is the worst observed but is it the worst expected? Is 40 minutes actually enough time for liquidators to act, especially in turbulent market conditions? If yes, then 85% LTV was a good choice. If not, then the LTV should've been lower.

To create Adaptive LTVs, we must answer those questions using only onchain data.

Solution

Implied Volatility

Implied Volatility (IV) is the estimate of expected price movement that we're looking for. If we assume, as in Black-Scholes, that price movements are Gaussian, then IV is equivalent to 1 standard deviation on the normal distribution:

The current price is the center of the distribution.

Example

At time of writing, TSLA is trading at $254 and its annualized IV is 52%. This means "the market" believes there's a 68% chance of the price being between $151 and $427 one year from now.*

*Most people apply IV additively, i.e. $p \cdot (1 \pm \sigma)$, but the finance papers use $p \cdot e^{\pm \sigma}$. For small values of $\sigma$ there's not much difference.

In our previous product, Aloe Blend, we built an onchain VolatilityOracle that uses Uniswap V3 volume and tick-liquidity to estimate IV. We reuse that logic in Aloe II to help compute LTVs.

Assumptions

• 5% swap discount is a strong enough incentive for liquidators close positions

• Liquidators can close positions in < 24 hours

Since we want liquidators to have 24 hours, we use daily IV. Since we want Aloe II to be robust, we assume a $5\sigma$ event which is expected to occur once every 4776 years. Governance can adjust this between $4\sigma$ and $8\sigma$ on a per-market basis.

With those numbers in hand, we can estimate worst-case scenario prices－one below the current TWAP, and one above it:

uint256 scaler = exp(nSigma * iv);

uint256 lowerProbePrice = TWAP * scaler;
uint256 upperProbePrice = TWAP / scaler;

Finally, we check whether the Borrower is unhealthy at those probe prices. For nSigma=5, this is equivalent to asking "Is there a greater than 1 in 1,744,278 chance that the Borrower will be unhealthy at some point in the next 24 hours." If yes, liquidations are allowed.

Getting back to LTV...

Aloe II's Borrowers are powerful－they allow for leverage on raw assets as well as Uniswap positions. But if we consider the simple case where you provide one asset as collateral, borrow the other, and withdraw it to your wallet, there's an equivalency between probe prices and LTV. This "effective" LTV can be calculated as follows:

const nSigma = 5;
const {iv} = await oracle.consult(somePool, Q40);
let ltv = 1.0 / (1.055 * Math.exp(nSigma * iv));
if (ltv < 0.10) ltv = 0.10;
if (ltv > 0.90) ltv = 0.90;

You'll notice we clamp the LTV to be between 10% and 90%, regardless of what IV is saying. Also, for reference, you can find ETH IV data here.

Note the log-scale.