The Curve LP Token Pricing Method

A central part of the Conic Omnipool ecosystem is formed by the Curve LP pricing methodology we propose. Users of Conic Omnipools will indirectly engage in single-sided liquidity provision to several Curve pools. Many of these Curve pools, rely on a custom invariant to determine the price of an asset in the pool and to obtain a value for the pool’s LP tokens, outlined in the stableswap whitepaper (https://curve.fi/files/stableswap-paper.pdf).

While the stableswap logic ensures comparatively stable prices, users can still imbalance a Curve pool (for instance using a flashloan) to influence the prices in that pool.
This gives rise to a number of attacks that must be prevented when engaging in single-sided
liquidity provision. Specifically, any transaction with a withdrawal or deposit of only one asset
into a multi-asset pool on Curve is susceptible to these attacks.

To preclude this sort of attack from happening during the rebalancing of a Conic Omnipool and during deposits and withdrawals, we require a manipulation resistant LP token pricing mechanism.

The mechanism we propose towards this end, relies on the invariant of the Curve pool and price oracles.

Computing the Amount of each Asset Deposited in the Curve Pool

Asset A:

Given the current invariant value and the price of one of the two assets (asset A) in the Curve pool (obtained from a price oracle), we can compute the amount of that asset currently deposited in the Curve pool under current market prices. Specifically, we solve the first derivative of the positive root of the invariant solved for asset B for asset A at the current oracle price. As there is no closed form solution for this, we employ Newton’s method to arrive at an iterative solution. Since we rely on an oracle price rather than the Curve price, which can be manipulated, this is resistant to flash loan manipulation.

Asset B:

Now that we have computed the amount of asset A in the pool, we can use this in combination with the invariant to compute the amount of asset B deposited in the pool by employing the iterative solution technique implemented in the Curve pools.

With these two asset amounts and the prices for both assets obtained from the oracle, it is now straight forward to compute a fair value for the pool’s LP token.

POC Implementation

A proof-of-concept Python implementation of the outlined methodology can be found at GitHub - ConicFinance/POC_curve_lp_token_pricing: Python implementation of the Curve LP token pricing method. A full mathematical derivation is included in the Conic whitepaper (https://ipfs.conic.finance/whitepaper.pdf). Note that the POC implementation is valid for stableswap version 2.8 – other versions may employ slightly different invariants, but will be covered by the final Conic LP token pricing mechanism.

2 Likes

Hey,

While browsing I stumbled upon this criticism but I am unable to tell whether it’s valid or not so here goes:
" Why get an estimation of pool assets using an oracle price when you can just check the balances of the pool"

Thank you

Balances can easily be manipulated, via flash loans for example, so it would not be safe to use them directly to price the LP tokens.
There has already been several exploits because of this, for example, the Warp exploit.

1 Like

Thanks for the reply.
Happy to see you’re trying to stay ahead of things instead of just going for the low hanging fruit :slight_smile:

For anyone who can’t open the link like me, just go to cmichel.io and do a CTRL+F search for “pricing” :slight_smile: