Comment on page
Conic Omnipools
Omnipools are liquidity pools that Conic utilizes to allocate a single underlying asset across multiple Curve pools. For example the USDC Omnipool accepts deposits of USDC, and will allocate that to several Curve pools that have USDC as an underlying token.
Conic supports v1 Curve (i.e. stableswap) pools that have a Chainlink Oracle for all underlying tokens of the Curve pool. This includes Meta pools.
CRV, CVX and CNC accrue to stakers of Omnipool LP tokens. By default, Omnipool LP tokens get staked and unstaked via the Conic UI when a deposit or withdrawal is made.
Omnipools rely on an incentivized and passive rebalancing system based on deposits to and withdrawals from them. When a user deposits into an Omnipool the deposit will always be made to the least allocated Curve Pool relative to the target distribution, and when a user withdraws it will come from the most over-allocated Curve Pool. This means that with regular deposits and withdrawals the pool will maintain a balanced state.
To incentivize regular deposits and withdrawals, CNC emissions are given out to users who deposit into Omnipools while the pools are imbalanced and the rebalancing reward period is active. This period is activated after Curve pool weights have been updated in an Omnipool (i.e. after a LAV). The CNC received will be based on the amount deposited, and will also increase over time while a pool is imbalanced, and will stop when the pool is balanced again.
Once the Omnipool is balanced within an allowed deviation threshold, CNC emissions to incentivize deposits will be set to zero until the next rebalance period.
The amount of CNC emitted depends on the deposit amount and increases with time. This incentivizes users to rebalance as soon as CNC emissions exceed the price impact incurred from making a deposit.
For bots and arbitrageurs who are looking to rebalance Omnipools for CNC rewards, they can do so by calling the rebalance function. Calling the rebalance function is more efficient than manually depositing and withdrawing from Omnipools and can result in a higher amount of CNC rewards for users.
Before calling the rebalance function, the caller must first approve spending for the reward handler to spend the underlying they are depositing. There is no change to how CNC rewards are distributed (emitted directly to the user’s wallet once the transaction completes). The rebalance function takes the
underlyingAmount from the user, deposits it into the Omnipool, and then withdraws it. It then returns the remaining underlying to the user (which will likely be less than the original amount due to Curve swap fees). Users who call the rebalance function will only receive CNC rewards if rebalance rewards are active at that time.The rebalance function takes two additional parameters;
minUnderlyingReceived (which is the minimum underlying the user is willing to accept to receive back) and minCNCReceived (which is the minimum CNC rewards the user is willing to accept for their rebalance). It is recommended to use these values to protect against MEV bots sandwiching your transaction.
Although the majority of rebalancing transactions will be done by bots, users wishing to call the rebalance function manually can do so through the contract on Etherscan.
To incentivize regular deposits and withdrawals, CNC emissions are given out to users who deposit into Omnipools while the pools are imbalanced and the rebalancing reward period is active. Note that rewards are not paid out on withdrawals. For active LPs that wish to participate in the rebalancing process, they may want to use the
rebalance function of an Omnipool.By design, Omnipools do not allow to be imbalanced deliberately. When depositing into an Omnipool, the deposit will be made into the Curve pool that is the most under-allocated relative to its target allocation. Similarly, when withdrawing from an Omnipool, the withdrawal will always be made from the most over-allocated Curve pool. The exception to this is when the deposit or withdrawal is so large, that it would push the balance of that Curve pool the other way, resulting in it being more imbalanced than before and over a specified imbalance threshold. In this case, a full deposit is made, where the deposit is split over several Curve pools such that the Omnipool is relatively balanced after the deposit/withdrawal.
All deposits into an Omnipool are always made directly to one or more Curve pools. However, the Curve pool LP tokens may not always get deposited (and subsequently staked) on Convex. This depends on a ratio of Curve LP tokens that may remain idle.
An LP may stake their Omnipool LP tokens to receive an amount of CNC that depends on the LP's value of staked LP tokens relative to the total Conic TVL. Additionally, stakers of LP tokens receive an "LP boost" on their vlCNC balance that is applied to the balance for voting and proposal creation. For more info, please refer to the voting and boosting section.
In an Omnipool, each supported Curve pool has a liquidity allocation weight, which determines the amount of liquidity that the Curve pool should receive. These weights get updated in biweekly liquidity allocation votes (LAVs).
No. Omnipools distribute CRV and CVX as soon as the user claims their emissions. However, any "extra rewards" (e.g. SPELL or FXS) that a Curve pool receives will be compounded in CNC.
Yes, Curve pools that do not directly hold the underlying asset are supported. For example, the USDC Omnipool would support the 3CRV-MIM pool. This is handled in the Omnipool contract by providing liquidity first to the 3CRV pool, and then to the 3CRV-MIM pool.
In the event that a token depegs in one of the Curve Pools, an action can be triggered by anyone which helps to protect the Omnipool from the impact of the depegging. This action results in the weight of the Curve Pool being set to 0 and CNC rebalancing rewards being enabled again for deposits. The effect of this is that the Omnipool should withdraw funds from the depegged Curve Pool and move them to other Curve Pools on withdrawals.
Note that the
handleDepeggedCurvePool function does not rebalance the pools automatically. This will still need to be done separately (e.g., via the rebalance function).The definition of a Curve Pool being depegged is if the Curve LP Token has deviated by more than the depeg threshold since the last time the Omnipool weights were updated. The depeg threshold can be updated through governance, it is initialized to 3% on contract deployment.
Last modified 4mo ago