LP risks in Curve pools, pt. 1

Published in

Neuron

6 min readApr 27, 2022

This article will outline the basics of our risk model for stablecoin assets and present the steps we were taking to land there.

UPD: we’ve obviously removed MIM-UST from our future pools due to depegging. Not to say it had the highest risks on our model so it would have had the lowest allocation limit 🤓

Why?

When considering DOVs, one should always remember that the whole protocol’s universe of pools is akin to a discrete investment portfolio (only available to everyone and democratized). Each pool/vault is an asset position with its risks, limits, and exposure. Yeah-yeah, someone will call out, “when aping, it’s all just bets, nothing substantial!” but we’re doing risk management here.

Proper risk management is paramount to any investing process, and we’ve decided that we require some framework to measure the second part of Neuron — yield-bearing collaterals.

A probability refresher

Depegging, or losing the peg/exchange rate stability, is one of the most dangerous things that can possibly happen to a stablecoin — think of it as a gymnast losing balance on a rope.

If we can define a certain ~true probability of a coin losing its peg during some period as P(depeg, asset 1) or P(d1), then the probability of it staying intact is 1 — P(d1).

Take this for a second asset as P(d2), and our formula of a pool with two assets depegging will be 1 — (1 — P(d1)) * (1 — P(d2)), or 1–1+P(d1)+P(d2)-P(d1)*P(d2), or P(d1)+P(d2)-P(d1)*P(d2).

Drawing the equation output over the rising sum of probabilities.

1. Model requirements

A pool’s risk score depends on several parameters. The first one is the stablecoins present in the pool, which means we have to estimate the depeg risks. Then a formula is needed to convert the separate constituents into a probability of liquidity providers getting yield.

So, a stablecoin’s design is the first and foremost factor — it’s the shield against depegging itself. But we shouldn’t forget about two additional parameters determining peg stability: liquidity pool depth and constant A. Why?

Okay, let’s imagine that a stablecoin is nearing depeg:

Everyone starts panic-selling the depegging asset in an LP pair of depeggingAsset/stableAsset, thus leaving more depegging asset and less stable asset in the pool, respectively
The price follows the StableSwap curve as follows:

Source: https://medium.com/dragonfly-research/what-explains-the-rise-of-amms-7d008af1c399

The things defining the price behavior are liquidity depth (how much X exchanged for Y before an _% change in price) and A, determining if the price will move: curvy (dat curves…) or linear constant sum.

Source: https://arxiv.org/ftp/arxiv/papers/2105/2105.02782.pdf

Those are, in essence, secondary risk factors. A stablecoin’s design is primary — it’s the shield against depegging itself, while depth and A can only postpone LP share dropping dangerously in value. We’ll go over both in-depth a bit later, promise!

So, our final score will be a weighted sum of risk factors mentioned:

2. Choice

First, we will choose our asset universe — the pools we will send the collateral to. To do so, we can go to Curve and filter by USD:

🌌 Our Curve pools’ universe, after some adjustments, will be as follows:

3Crv
alUSD
FRAX + 3Crv
FRAX + USDC
LUSD
MIM

3. Non-market risks

We’d stumbled upon a great article by Serenity fund providing a classification of stablecoin design risks and chose to use it (kudos to Serenity!)

4. Market risks in-depth

Some time ago we settled on A constant and Curve pool depth as the weighing factors…

Constant A

If you dive into the Stableswap whitepaper, you’ll notice the equation consists of two parts, quoting awesome peeps at Balancer:

In an ideal scenario, it would make sense to simply allow 1-to-1 trades for these assets; this would be a Constant Sum curve. In a worst case scenario where one or more of these assets loses their peg and their value diverges, it would make sense to enforce trade rules for uncorrelated assets; this would be a Constant Product curve.

Price curve changing with respect to constant A. Source: Balancer docs

As such, more “established” stablecoins will have higher A (➡️ less slippage ➡️ you can exchange more x for y for an equivalent price movement in %) with 3Crv topping the chart at A=5000, and the average stablecoin from our universe sits at approximately A=1400.

Pool depth

Pool depth complements A and allows more x to be exchanged for y for an equivalent price movement in %. A simple example: you’re sitting on top of a 10M pile of stablecoins and want to change it to another stablecoin losing the least. Would you rather prefer those to be USDC and DAI, or USDP and USDT?

Turns out pool size (and A) mean, like, a lot. Will you either use a 3B 3Crv pool or a 30M USDP|3Crv pool and pay ~0.03% or ~35%. This will make sense during unstable (pardon the pun) times when a coin risks depegging — it will either stay intact longer or go wild, depending on those. Those two are definitely included in our mighty little scoring model.

Preparing to pay gas fees on L1 when exchanging $100.

Wrapping up

After risk-weighing all of the factors:

maximum stablecoin risk from Serenity’s paper is 5, and it’s the greatest effector: the way a coin is designed means the world. So let’s say a weight of 5 can just stay there;
constant A means some, yet it’s not that much, and it’s ~dynamic, i.e. it’s possible to change it. So we’ve normalized as weight*(1-A/maxA) and left it a weight of 0.5 points;
pool depth is one of the defining factors. We’ve left at 1 point of weight. However, to do a pool depth → risk score calculation, we’ll have to implement another function, bonding to some output curve.

Let’s define our requirements:

For pool depth → 0, we should have a risk score → maxWeight;
Subsequently for 3Crv pool depth, we’ll have a 0 risk score;
We’d want a simple function, as we’re simple men…
The scoring model should “reward” bigger pools as they’re more likely to be safu yet disavow shallower pools as they’re increasingly riskier

As you can see, a simple function as 1-x^n satisfy our requirements, so we’ll propose using 1-x² for the time being.

We’ve tried so hard and got so far…

A-and we’re left with the following formula: RS(x) = RS_0(x) + weightPool*(1 — (poolsize(x)/poolsize(3crv))²) + weightA*(1 — A(x)/A(3crv))

Everything constitutes for a table:

And a simplified table:

Yeah, MIM can be risky.

Let’s also take a look at Liquity | LUSD, which is less risky than MIM or alUSD despite being a lot less shallow of a pool or being the same risk-wise + sporting higher A respectively. So, we can conclude that the model works as planned.

The second part will explore more scoring factors, pool calculations, and implement a semi-automated scoring mechanism to choose pool limits.