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.